Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Nemuri Neko

Pages: [1] 2
1
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 19, 2006, 08:18:02 am »
I think 8 layer is going to be realistic. this will have some very finepitch components on it with a small T&G ( not sure at the moment but I will check it out ) I'm not sure what debug provision you are thinking of putting on it but I think you will want 100% via coverage even in the final version. This will take a bit of routing.

I would vote for leaving the CF off and concentrating on the USB and ATA, both waaay faster than the CF.

The pin muxing on this device is complicated isn't it? What I don't understand is why the designers didn't mux the PCMCIA and ATA and leave the flash interface alone!!! Still a lovely device tho'.

2
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 11:07:49 pm »
Quote
i keep getting "no such channel" when i connect on irc. probelly doing somthing wrong at my end

to some extent it does affect the design. it is intresting as it tells us what will take a performance hit and what wont. but does it apply when you stick the flash on an 8bit interface? from what i read doing that causes no shared pins at all. WEIM sounds great but it still sounds as if we need a bit of translation logic, i will have to break out a data sheet or two and look at how to wire it all up

can you give me a page number where it talks about which pins are shared and which are not as i remeber seeing one but cannot find the page anymore

kexec info should be on the arm linux website, i dont know tho full details but i assume its fairly simple. there wouldnt be a file format, only where you get loaded to and the location of the command line args
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135630\"][{POST_SNAPBACK}][/a][/div]



The problem is the data is spread over 3 documents. The pin sharing is in a document called MCIMX31 and is on page 56. The MCMX31RM also has a far more complicated version on page 16-14

NAND does have a dedicated io bus. If you have a look at the operation of NAND it does not have an address bus or data bus, but an I/O bus. This carries both commands and data. So you issue a read on the I/O bus, then wait, then do a read ( or write ) on the same bus, the same pins. It is easy to wire up if you have a nAND controller, but is really not efficient.

The WEIM doesn't really need much external circuitry. It might need a buffer on the low 12 address pins to de-couple the devices from the SDRAM so it doesn't add any additional capacitive load to the SDRAM.

DB: I'll do a full bandwidth comparison of the 2 busses if you like. Fancy having a go as well just to make sure we get it right

3
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 09:26:31 am »
Well on reading the datasheet again, it appears that it will overlap transactions depending on the order that they appear, whilst it does overlap the SDRAM acceses to a large degree, the other acceses will complete before a new one is issued. This will only affect the system throughput if multiple masters are trying access differing resources. If the graphics subsystem is doing an access to SDRAM at the same time as the CPU wants flash, the CPU will stall until the SDRAM transaction had finished.

The arbiter will allow both the CPU and GPU to have queued transactions to SDRAM, but in the above case the CPU would still be stalled if the GPU was doing a transaction to SDRAM and then the CPU issued a transaction to SDRAM, but the impact would be less.

Perhaps we should stay on topic as this really doesn't affect the design too much  

4
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 08:41:14 am »
Quote
What you say here about the EMI contradicts what has been said earlier

if it stalls the SDRAM then it must share the SDRAM adress and data pins if so then i will avoid it as it is WAY to slow

i still dont think everyone is on the same page. it seems that some points have already been adressed in other posts that people have not read or do not understand. i will clean up the wiki and post the overview here to clear it up. we are getting to much fragmentation here

as for the CF vs ATA, think 16MB/s vs 66MB/s with DMA acsess. (not that that really means anything) and also think shared bus vs dedicated bus. keeping in mind that the CF card might not reach that speed and those are theroaticl maximums
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135545\"][{POST_SNAPBACK}][/a][/div]

It's all in the nature of the transactions. Only the Address pins are multiplexed between WEIM and SDRAM, and because of the burst nature of the transactions they will not interfere too much with each other. Because each is actually attached to a different arbiter it is my understanding that these transactions can overlap, in that one can start before the other finishes. Even within the same arbiter they can and will overlap, being held until a slot is ready. Now the WEIM flash interface because it is fast, and because it is on a different path ( ie internal bus in the memory interface ) will not slow down the SDRAM access to any noticable degree. When DMA is underway for the graphics subsystem, then the WEIM will rarely "interfere" with these transactions because of the overlapping or interleaved transactions. With the PCMCIA things are totally different, in that a transaction can be slow, very slow, and held off by the PCMCIA card ( or CF card ) using the control pins. From my reading of the datasheets, this "beat" of a transaction will not be split or aborted, and thus will cause overall system degredation. To a lesser extent ( much lesser ) the NAND interface suffers the same problem. It can have relatively slow transactions, but when a single "beat" of a transaction is complete the arbiter will throw it off the bus if something else comes along. The request from the SDRAM controller is cascaded down to the peripheral arbiter, and so will take highest priority.

The address phase of each burst transaction is a small percentage of the total transaction time that it should not impact noticeably on the other arbiter.

The NAND controller decouples from the SDRAM bus by using the NAND IO bus, which is comparitively slow when put against the WEIM, not particulary efficient, but is easier to hook up.

Again all this is moot in that if you are only using the flash to boot then it is as good to put it on NAND controller. It will be a little slower to boot and launch off of, but I doubt anyone would notice.

I think you are getting hung up on the shared/dedicated bus thing. The NAND bus will always be slower than the WEIM. The SDRAM will barely be slowed by the WEIM, and the flash on the WEIM will produce a faster system. As you do not intend to run from flash then it doesn't matter. If you intend to load apps from flash, then again I would consider the WEIM.

5
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 06:58:29 am »
Quote
No if there is no performance hit from the CF card because it has its own dedicated IO pins then i will reintroduce it
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135536\"][{POST_SNAPBACK}][/a][/div]


It will definitely stall the SDRAM, also because of the async nature it could slow things down unacceptably. I'm not a fan of CF anyway, there is nothing that it cannot do that could not be done faster and better with SD or USB. Looks like some sort of consensus is breaking out  anyway, we definitely need a faster way to knock ideas back and forth..

6
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 04:50:34 am »
Quote
cant really see any infomation to prove or disprove the WEIM  stuff, as far as i could tell the adress and data pins are all shared between the EMI stuff if it isnt, then think of the posabilities

if this is the case then i may bring back the CF slot

i can see your point about XIP in that case however we are only really using it to boot and i was going to use squashFS on it which would mean no XIP
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135523\"][{POST_SNAPBACK}][/a][/div]
aaah, so the CF has gone? If you are just thinking of using the flash to boot, why does it affect whether there is a CF in the system?

7
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 04:12:48 am »
Quote
I was under the impression you wanted to put the flash on the same bus as the DDR using WIEM stuff. i guess that is where the confusion is comming from (seems to be alot of that here i will ask for that seperate fourm)

XIP is nice but with huge amounts of RAM (ie greater than 64MB) i dont see the point really as i would expect the program to be running out of cache rather than directly from the DDR RAM. running form flash rather than cache would cause a huge performance hit so i would avoid it however there are times when XIP is handy

but yes the flash is only to bootload thats why i say to chuck it on that little 8bit buss that was designed for the specific purpose of booting the device

with the keyboard i am thinking that we make the bottons as large as posible with no gap between them so that we only have to cut out a huge rectangle and push it throgh.

yeah i should have clarified on the membrane keyboard, i dont like that no tactile feedback style ethier
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135519\"][{POST_SNAPBACK}][/a][/div]


But WEIM doesn't sit on the SDRAM bus. Also I wasn't thinking of making the flash non-cacheable, but was thinking of not having it copied to RAM to execute. You can have the Flash cacheable, no problem there, it just seems a waste to me in an embedded environment to copy code from flash to execute rather than just XIP. Again, it does not mean it is not cached.

8
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 04:01:52 am »
How about breaking this up into seperate threads....

starting new threads for keyboard, screen, memory, expansion. It seems that this thread is too large and daunting to any newcomers to the project. Can we talk the admins into giving us our own section?

9
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 03:56:55 am »
Quote
keyboard is nice but too big

i was under the impresion that the cerrunt Z keyboards are membrane bassed and not switches. the mebrane keypads give the option for the metal dome (yaou have to look for it in the links i gave out)

32bit all the way, i am aware of the LCD causing that much of a performance hit however i belive the flash is a performance penalty comes from times where you need data from flash and DDR ram at the same time (ie watching a moive) also some have mentioned audio work with this thing.

ethier way i have repetadly said that i only want a small flash area to bootload so it dosent matter how the flash is connected, it just seems to be easier to interface to if we chuck it on the 8 bit bus as i dont see the flash chips as needing high speed acsess

i know putting the flash on the ddr bus makes wireing simpler, i will have to check the boot diagrams and see how placing the flash there will affect the over starting of the CPU
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135511\"][{POST_SNAPBACK}][/a][/div]


The flash isn't on the SDRAM bus, it is separate, unless you are talking about the core side of the arbiter, then it is unavoidable and moot because everything is contending for this bus. If booting is all that the flash is needed for then I agree totally, keep it as simple as possible. I do like the idea of XIP tho' ( although it appears I am the only one  ). XIP will also give an advantage when the bus does get clogged with graphics data. because the GPU and IPU can operate without CPU intervention and using DMA around the CPU busses you can effectively get 100 % of flash bandwidth to run from, as opposed to 25% of SDRAM bandwidth.

We don't want to get bogged down with semantics anyway

I think I mis understood what you meant by membrane and keyswitch. I thought you were thinking of something along the lines of a cheap calculator style membrane, or one like on the ZX80, and keyswitches along the lines of..well a keyboard switch

If there are keyboards avaialable off the shelf, then that is the way to go. It will be very hard to make a keyboard from scratch. Getting a scratch built case to fit will be get the maker huge kudos

10
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 03:07:08 am »
Do we have an IRC channel to have a chat? cos some of this is going to get very loooong and very technical. Toys will be thrown, chickens counted and milk spilled before things are finalised, all of which is going to take up a lot of pages on this board

11
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 03:02:01 am »
Quote
its a real chiken and egg problem till you look at the data sheet and relise that you can send this thing code to be executed over usb

when faced between the option of flashing over usb or jtag i think more people would have a usb port than jtag equipment

onec everything is flashed then we can disable flashing over the usb port (must double check that)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=135502\"][{POST_SNAPBACK}][/a][/div]


First boot can be done over USB, and thus a loader can be loaded  Then a change in jumpers, or fuse burn can disable this option. There will be nothing that can be done about a determined engineer re-flashing, but data already flashed should be able to be made safe. It is not tamper proof, but is what the datasheet describes as tamper evident.

12
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 18, 2006, 02:57:23 am »
Ok, lets get rid of the flash slowing down the SDRAM meme. The flash whether NAND or NOR will not slow down the SDRAM in any meaningful way. They only share a bus in the sense that they both use AMBA peripherals to the CPU, but the arbiter will mean things move along at a good pace. If you want to look at the real culprit for system slowdown then begin to look at the LCD. Having a look at some of the app notes the iMX looks to have to hand over up to 70% of available bandwidth for a VGA screen running 3d graphics, this will only get worse as the resolution increases. This includes using the 3d engine so has a high pixel rate that would only be seen in games.
Now, these tests were done using 16 bit SDRAM, and I think the plan is to use 32bit mobile DDR SDRAM so this whould halve the memory requirements. But this is something to keep in mind if you want the result to run 3d apps.

Over to the keyboard, thinking about having a membrane over keyswitches.... I'm not sure how that will work. I have seen membrane keyboards, but these usually have a conductive layer over a spiral of etch, so when the "key" is pressed then the contact is made. The best adaption of this I have seen are in old HP calculators and pocket computers. These had a separate keycap pivoted above a shallow metal dome. this gave very good key feel for not much vertical height.

Surface mount keyswitches will definitely provide the best feel for a keyboard, but even the most shallow of these are tall, add to that the keycap that has to be placed over it and you have a keyboard with a height of 5mm or over. a better solution is to pivot the keycap below the upper deck height of the keyswitch, but this is very hard to engineer.

Last time I did something similar Fujitsu had some nice embedded keyboards off the shelf, but they are larger than I think this forum wants. Check out the following pdf

http://www.fceu.fujitsu.com/pdf/Datasheet_FKB-7681.pdf

The amount of things in this design may very well mean that a keyboard of this size is useable. They definitely feel ok to type on.

13
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 13, 2006, 09:19:54 am »
 No I don't work for sharp, but I have designed a few PDAs and phones

Getting a backpack functional would be ok, getting one elegant will be hard. You can have one that simply "bolts up" to the mothercase and physical connection will be made by mechanical tightening. To have a nice sliding one that looks professional is a lot harder. A good but sad point is to keep everything square and blocky, so no curves and definitely no compound curves!!

Unfortunately I'm off for the weekend so will be back reading on Tuesday, so maybe we can hammer out some details then... maybe do it away from this thread as it is getting a bit large and unmanageable. In the meantime follow the mantra of the great Mr Chapman "Simplicate, and add lightness"

14
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 13, 2006, 08:24:29 am »
In an ideal world then a backpack would be great, particularly with a USB hub. Especially to make it extensible to 2 or 3, but again there is the engineering effort to think about. One case is hard but having 2 cases that fit together in a neat way would be an order of magnitude more difficult. I think SD is the way to go, support is coming on a treat with linux.
Having said that  I have often thought about serialising the CF interface, pumping it over a thin LVDS line and deserialising it at the other end, kind of like a poor mans SATA. This way you get large storage and small, case independant form factor. decoupling the CF from the case would make things neater.

Prolly an IRC chat would be a good thing, have a party line with all interested parties if possible. One thing for sure is that all the people cannot be pleased. A lot of this sort of these collabortive projects fall over because in all the initial enthusiasm everybody gives their wish list  but in reality they would not use much of on their wish list and the project gets bogged down in complexity. I for one would like Doc Browns flux capacitor

Please don't get me wrong and think I am pessimistic or sniping at anyone in particular. One thing that springs to mind for me is the 7.1 sound that was mentioned. To use it you would have to be in a large room, with large speakers and a large receiver.... surely such a room would have a multimedia device far better suited to the job of producing 7.1 sound than a super zaurus. To justify 7.1 you would have to be watching HD content, that requires a lot of bandwidth and a lot of processing.... I am prolly missing the point, but this is a homer, it has to be realistic or it will not get built.

Wow, do I sound the billy come lately who is p*ssing in the porridge

15
PocketPenguin / Build Your Own Linux Powered Pda
« on: July 13, 2006, 07:53:05 am »
Hi,

hmmm... with the advent of USB I would question the need for CF and PCMCIA. I am not sure how much each would get used. I'm not sure enough people would in reality use them enough of the time to warrent the board space, performance hit and case complexity. Remember, each hole has to be carefully engineered and the fewer holes the better. In REALITY, who will use the CF when the USB and SD is there? Wouldn't a better use of the case space be to have a USB "bay", a void inside the case that would be big enough to take a couple of de-cased USB "dongles" one for wireless and the other for bluetooth or a flash drive. It would be cheaper and quicker to use an existing device for these functions than to place on board. The KISS principle reigns supreme for homers. If someone else has done it better, cheaper and easier, then stand on those shoulders

Pages: [1] 2