x
This website is using cookies. We use cookies to ensure that we give you the best experience on our website. More info. That's Fine
HPC:Factor Logo 
 
Latest Forum Activity

A Call for Help: Debian.

[Frozen]
« Prev 1 2 3 4 5 6 7 8 9 Next »
Frozen
sophisticatedleaf Page Icon Posted 2005-10-17 12:42 AM
#
Avatar image of sophisticatedleaf
H/PC Elder

Posts:
2,294
Location:
Sunny California
Status:
Hahah, it's configuration is similar to the kernel.

Anyone want a httpd server? It HAS one!

-The answer is yes, because it's another feature and it won't use up much memory.
It will not use inetd, I am trying to get away from that. I will just set it to port 80.

--Even if this does come to 7mb, I am really adding a ton of functionality to the system, so it is better than before anyways. This is an amazing piece of software!

---If no one has noticed, I am really taking some big steps away from Debian here. In the end, I will create a fake dpkg status file, that will tell the dpkg (apt) system that it's bulkier versions of core software are installed, so it will still be useable by anyone who needs it. But emphasis is really being placed on ipkg, or my own compilation of the Slackware package management system. More on this later! (Ok, the plan is to put the binaries into .tgz files before the release, to make adding and removing much easier!)

EDIT: Admins, this is ridiculous. I post, and it doesnt show after the thank you message, and after I refresh. Again, again, and again. Then, when I post it and get the wonderful time out message, I know that it was successful. And when I refresh that time, THEN all my posts show up! What is that, four tries?

EDIT2: Hahaha, this is a cute tutorial for busybox. Watch it, and you will know what I mean.
You know, cross-compilers are really starting to get on my nerves. The ones that everyone tells people to use, simply DO NOT work! It is dying on the routing stuff. Why? Who knows. I'll try the uclibc compiler (the one the busybox coders use, so it had BETTER work...). Anyways, I accidentally compiled it for x86 , and the binary was only 548kb. That is absolutely incredible. There easily could have been 15mb of packages in there...Anyways, even though busybox has login possibilities, I disabled them, and will continue to use tinylogin. I assume that a program made for a certain task is better at it. And considering the trouble busybox has caused while tinylogin worked on the first try...

Edited by ProgramSynthesiser 2005-10-17 12:56 AM
 Top of the page
cmonex Page Icon Posted 2005-10-17 8:38 AM
#
Avatar image of cmonex
H/PC Oracle

Posts:
16,175
Location:
Budapest, Hungary
Status:
ProgramSynthesiser - 2005-10-17 6:42 AM

EDIT: Admins, this is ridiculous. I post, and it doesnt show after the thank you message, and after I refresh. Again, again, and again. Then, when I post it and get the wonderful time out message, I know that it was successful. And when I refresh that time, THEN all my posts show up! What is that, four tries?


now you can understand others with double posting... same situation.
 Top of the page
karloch Page Icon Posted 2005-10-17 5:30 PM
#
Avatar image of karloch
Factorite (Junior)

Posts:
48
Status:
ProgramSynthesiser - 2005-10-17 2:57 AM
-Thanks for the input, I am happy to hear it. I take it that you will be a beta tester?

EDIT: gtmess looks EXCELLENT! I will definitely add this to the release. Thanks! You seem to have a good knack at package selections.

Thanks to you for your efforts. I'm just suggesting packages that I have used and I would find them useful on the Jornada 720.

Of course I will be betatester, but I have to find a CF card yet. There is some things that are worriying me about Linux on Jornada 720:
    * CF card lifetime. I have heard that type 1 CF cards have limited lifetime of readwrites and it can be kinda of troublesome running Linux. I can't use a Microdrive on the PCMCIA slot because I have there the wireless 802.11 adapter, so I have to stick to type 1 CF cards. Is there any type 1 card without this limitation?

    * Jornada 720's hardware support. Until what point is the distro supporting Jornada 720 hardware? I mean:
      * Videodisplay support (2D acceleration)
      * Touchscreen support
      * PCMCIA support
      * Audio support (volume control)
      * Microphone support
      * PowerManagement Support (Suspend, screen blanking, brightnest and contrast control)
      * Winmodem support (NOT NEEDED!!)

    I would like to know how to power off the device if we are using Linux. I have heard that is not possible to fully support PowerManagement without a flashboard for the Jornada 720... and of course, a flashboard is a very rare item. I have heard also that Kernel 2.6 has better Jornada 720 hardware support that the 2.4 one.

About packages, it would be good to include also mpg123 and some oggvorbis player if there is audio support.
 Top of the page
cmonex Page Icon Posted 2005-10-17 8:01 PM
#
Avatar image of cmonex
H/PC Oracle

Posts:
16,175
Location:
Budapest, Hungary
Status:
karloch - 2005-10-17 11:30 PM


Of course I will be betatester, but I have to find a CF card yet. There is some things that are worriying me about Linux on Jornada 720:
    * CF card lifetime. I have heard that type 1 CF cards have limited lifetime of readwrites and it can be kinda of troublesome running Linux. I can't use a Microdrive on the PCMCIA slot because I have there the wireless 802.11 adapter, so I have to stick to type 1 CF cards. Is there any type 1 card without this limitation?

    I would like to know how to power off the device if we are using Linux. I have heard that is not possible to fully support PowerManagement without a flashboard for the Jornada 720... and of course, a flashboard is a very rare item. I have heard also that Kernel 2.6 has better Jornada 720 hardware support that the 2.4 one.


hey dont worry just don't use a swap file on the CF.

i heard real suspend is not possible without a flashboard. screen will be turned off and cpu speed will be reduced but that's it i'm afraid...
 Top of the page
sophisticatedleaf Page Icon Posted 2005-10-17 10:44 PM
#
Avatar image of sophisticatedleaf
H/PC Elder

Posts:
2,294
Location:
Sunny California
Status:
Ok. Whoever said that full suspend is not possible without a flash board does NOT know what they are talking about in the least! This is the way suspend works: Power down main system, cpu, and ONLY keep power going to the RAM. Now, if people continue to think that this relies on a piece of hardware, then the following will happen:

"Oh, we have the flashboard now. That means that you can shut off the computer. Who needs suspend?"

We need real PROGRAMMING to get the suspend to work, not an expensive chip! I would like to talk with whoever first stated that. It is driving me crazy that people think that they have to buy something for functionality that isn't remotely linked. Now, if we are going off of the backup battery, that might be another story. But suspend is POSSIBLE without the chip, we just need the software to do it!

Now, for the cf. Hahahah, don't worry about breaking the thing. Get a 512mb sandisk and it will last....well I have put mine through absolute torture and still have not gotten a single error. Get an Ultra II 512mb and it will last even longer. I have now realized this, and am only getting a microdrive for the space, and I guess the knowledge that it will only die if I drop it. But since you are not making the distribution, you really do not need to worry.

Hardware support? Waiting for the 2.6 kernel. Everything but the modem (which would be supported if enough people worked at it), works on the 2.4 kernel, but not as well. I see no need in totally hacking at the system with cheap scripts to get the stuff to just work on the 2.4 kernel, when the 2.6 will be excellent as soon as it is....released....one day.....

Touchscreen will work as soon as I decide it will. I will probably get it working soon, because the console has some uses for touchscreen. Gpm comes to mind.
 Top of the page
karloch Page Icon Posted 2005-10-21 2:42 PM
#
Avatar image of karloch
Factorite (Junior)

Posts:
48
Status:
Uhm... rollback?
 Top of the page
sophisticatedleaf Page Icon Posted 2005-10-22 3:35 PM
#
Avatar image of sophisticatedleaf
H/PC Elder

Posts:
2,294
Location:
Sunny California
Status:
What?
 Top of the page
cmonex Page Icon Posted 2005-10-22 11:06 PM
#
Avatar image of cmonex
H/PC Oracle

Posts:
16,175
Location:
Budapest, Hungary
Status:
ProgramSynthesiser - 2005-10-18 4:44 AM

Ok. Whoever said that full suspend is not possible without a flash board does NOT know what they are talking about in the least! This is the way suspend works: Power down main system, cpu, and ONLY keep power going to the RAM. Now, if people continue to think that this relies on a piece of hardware, then the following will happen:

"Oh, we have the flashboard now. That means that you can shut off the computer. Who needs suspend?"

We need real PROGRAMMING to get the suspend to work, not an expensive chip! I would like to talk with whoever first stated that. It is driving me crazy that people think that they have to buy something for functionality that isn't remotely linked. Now, if we are going off of the backup battery, that might be another story. But suspend is POSSIBLE without the chip, we just need the software to do it!


ive been thinking why no one has ever achieved real suspend with a linux running off a CF (or another external card, etc). or has anyone done this??
just think about it.. what happens when you suspend the device and then turn it back? it seems to me that the system needs to be able to use the CF before turning the thing back. can it be possible like in the case of the ROM? or is there a way to eliminate that need? anyway it really sounds difficult!... sorry if i talked too much nonsense but i think it is no coincidence that the flashrom version can have suspend with not much more work than these CF distros...


oh and i believe rollback is that you save the earlier versions of your work and you can get back to them if you screw up something... i think sometimes you're really in need of that
 Top of the page
Snappy! Page Icon Posted 2005-10-23 10:46 PM
#
Avatar image of Snappy!
H/PC Elder

Posts:
1,712
Location:
New Mexico, US
Status:
If the flashboard you folks mentioned is the same one as the one I read and know about, here's why a flash board is the other option besides programming.

From what I know programming can be done to properly enable suspend mode as well. The trick is knowing what address and values to set in the firmware (which may sit in a rombios-like chip or a dedicated controller chip) and asking it to switch the HPC to suspend mode.

However I doubt existing wince code actually make direct calls to the various components in the HPC to ask each one to switch to suspend, and hence doubt if any *nix implementation should start trying to do the low-level APM work.

If the wince is the making the low level APM calls, then there may be a slight problem here. Should it switch off the ram first or the cpu first? If it switch off the ram first, the apm code itself, which resides in the ram and is only POPped one opcode at a time into the cpu, is flushed and the cpu with its ProgramCounter would "hang" when it tries to execute the next instruction since the ram would have been switched off already. The remaining APM code that is supposed to switch off the CPU would not be available right? If the CPU is switched off first, then the remaining code would again not be executed and the RAM refreshing controller would still be running.

My understanding is that a controller firmware would initiate the suspend sequence upon a single atomic call from APM code in the OS / ring 0 (driver) level. The firmware (like in the case of the ROMBIOS of mobos in desktop or notebooks) works rather independently of the CPU or ram. It has to or else it would not be able to do things like the POST etc, which requires it to do initialization test if the CPU, ram and other devices are working. So it is able to switch off the various devices like CPU, RAM, video chip, bus, etc as required, depending on the APM mode selected and on the APM mode supported.

After suspend mode is achieved, it would probably be the only "code" running, more on a interrupt driver mode than not, listening to external triggers such as LCD touchscreen presses, power-on button trigger etc. In most cases, the RAM may be kept "alive" with lowest refresh cycle needed to keep the memory intact and not for read / write cycles. Once the resume trigger is detected, the firmware kicks in the resume code which wakes up the "sleeping" devices and (depending on implementation) starts the ProgramCounter and the CPU comes alive.

If the existing rom chip is like the rombios chip on mobos, it may very well contain the firmware to switch the various HPC parts to suspend mode and later respond to a resume trigger.

If that is the case, then the flash board that I have read about is supposed to implement the bootloader, contain the *nux rom, and even implement portions of the APM firmware that would switch the various HPC parts to suspend mode. The system APM libraries or code in *nix or wince would then talk to this firmware which would do the very low level work of switching of the devices as aforementioned.

The choice is really then to a) know the calls for existing APM firmware which is proprietary to HP or b) have the romboard which (may) contain APM firmware with known function registers known. Option a) as preferred by PS requires some fact finding to make the right call while option b) requires $$ for the romboard but would simplify writing the APM libraries since the APM calls to it would be known.

ProgramSynthesiser - 2005-10-17 8:44 PM

Ok. Whoever said that full suspend is not possible without a flash board does NOT know what they are talking about in the least! This is the way suspend works: Power down main system, cpu, and ONLY keep power going to the RAM. Now, if people continue to think that this relies on a piece of hardware, then the following will happen:

"Oh, we have the flashboard now. That means that you can shut off the computer. Who needs suspend?"

We need real PROGRAMMING to get the suspend to work, not an expensive chip! I would like to talk with whoever first stated that. It is driving me crazy that people think that they have to buy something for functionality that isn't remotely linked. Now, if we are going off of the backup battery, that might be another story. But suspend is POSSIBLE without the chip, we just need the software to do it!

Now, for the cf. Hahahah, don't worry about breaking the thing. Get a 512mb sandisk and it will last....well I have put mine through absolute torture and still have not gotten a single error. Get an Ultra II 512mb and it will last even longer. I have now realized this, and am only getting a microdrive for the space, and I guess the knowledge that it will only die if I drop it. But since you are not making the distribution, you really do not need to worry.

Hardware support? Waiting for the 2.6 kernel. Everything but the modem (which would be supported if enough people worked at it), works on the 2.4 kernel, but not as well. I see no need in totally hacking at the system with cheap scripts to get the stuff to just work on the 2.4 kernel, when the 2.6 will be excellent as soon as it is....released....one day.....

Touchscreen will work as soon as I decide it will. I will probably get it working soon, because the console has some uses for touchscreen. Gpm comes to mind.
 Top of the page
Snappy! Page Icon Posted 2005-10-23 11:10 PM
#
Avatar image of Snappy!
H/PC Elder

Posts:
1,712
Location:
New Mexico, US
Status:
cmonex - 2005-10-22 9:06 PM

ive been thinking why no one has ever achieved real suspend with a linux running off a CF (or another external card, etc). or has anyone done this??
just think about it.. what happens when you suspend the device and then turn it back? it seems to me that the system needs to be able to use the CF before turning the thing back. can it be possible like in the case of the ROM? or is there a way to eliminate that need? anyway it really sounds difficult!... sorry if i talked too much nonsense but i think it is no coincidence that the flashrom version can have suspend with not much more work than these CF distros...

oh and i believe rollback is that you save the earlier versions of your work and you can get back to them if you screw up something... i think sometimes you're really in need of that


Part of the answer lies with the previous post if my understanding of existing APM implementation for PC/desktop applies to embedded devices.

Case #1
If the APM resume code sits on the CF card itself, and the resume code is supposed to wakeup the controller for the PCMCIA/CF controller, then it would never get to wake itself up.

Case #2
If the APM code sits on the existing HP ROM chip, it would probably have to get the PCMCIA/CF controller and CPU + RAM awaken to running mode. As cmonex mentioned, it would need to wake up the CF then the CPU. But I wonder if the sequence in existing APM firware explicitly starts off the CPU/RAM and then the CF part. Getting the CPU/RAM to start running means the OS is alive and ready. Depending on implementation, this may mean the OS is required to reload the drivers for the CF or at least reinitialize them.

Taking a page from the desktop APM implementation, a "WM_QUERYSLEEP" is sent to running applications while certain devices like USB peripherals are switched to sleep mode. Upon resuming, they are then awaken in sequence. Some improperly implemented devices may fail to wakeup after a suspend and will only work with a reconnect. In some cases, it may cause PCs to hang upon resume.

If this applies to HPCs, and in particular J720 implementation, then existing APM code may be expecting a similar resume sequence, and thus would wakeup the CPU/RAM modules and then the CF controllers. This may cause the *nix OS to go bonkers as it tries to load up drivers for the CF controller, from the CF card itself ... which is still sleeping.

Maybe PS can paste some snippets of the APM code here and we can see what is the sequence implemented etc. Would be interesting to also find out the destailed implementations of the ROMboard and whether it contains APM firmware.

Hope I am making sense here ...
 Top of the page
sophisticatedleaf Page Icon Posted 2005-10-26 8:42 PM
#
Avatar image of sophisticatedleaf
H/PC Elder

Posts:
2,294
Location:
Sunny California
Status:
The APM code we need is in kernel 2.6, which is not stable yet. (For the 720) Would any APM code from the 2.6 kernel work, or does it need any existing 720 patches?

This is really far away from what I am doing, the drivers and kernel are not my project.

Snappy!, instead of keeping the APM code necessary to resume on the cf, why not just load it to the ram before suspend? It is not large, and the kernel loads itself at startup anyways... But if that happened, considering that the ram is getting power, it would send the signal out the processor, then that to the rest of the motherboard, and BAM! Wakeup sequence. (Correct?)
 Top of the page
cmonex Page Icon Posted 2005-10-26 9:08 PM
#
Avatar image of cmonex
H/PC Oracle

Posts:
16,175
Location:
Budapest, Hungary
Status:
ProgramSynthesiser - 2005-10-27 2:42 AM

Snappy!, instead of keeping the APM code necessary to resume on the cf, why not just load it to the ram before suspend? It is not large, and the kernel loads itself at startup anyways... But if that happened, considering that the ram is getting power, it would send the signal out the processor, then that to the rest of the motherboard, and BAM! Wakeup sequence. (Correct?)


i agree... or maybe this is not that simple that the "ram is getting power ... " etc. but something like that.. erm Snappy will explain it better

btw, Snappy, your explanation was excellent and easily understood (at least to me), as always!

now can someone show me a linux or similar running from CF and can do *proper* standby? i never saw one for the J720 nor for some other stuff.. not sure about mips netbsd for the z50 NEC 790 etc... Snappy?

Edited by cmonex 2005-10-26 9:12 PM
 Top of the page
matrixcore Page Icon Posted 2005-10-26 9:18 PM
#
Avatar image of matrixcore
H/PC Elite

Posts:
627
Location:
The Matrix
Status:
I think you're assuming too much about the boot process. a message from the jornada newsgroup that explains the thing

Michael Gernoth 18.08.05 - 10:18 (GMT)

There is no problem in suspending the Jornada as Windows does. The only
problem is the resume ;-)
IIRC the processor starts executing at 0x0 when being resumed. This is
in the mask-rom on jornadas without flashboards and contains a branch
to 0x1000 where the Windows CE bootloader starts and tries to boot CE.
There is no way I have seen from disassembling the bootloader to
jump somewhere else in the early initialization, so we could get the
linux-resume code to run.

The only thing I can think of would be to find out how Windows
a) determines that the machine was suspended and not shut down
b) saves the registers in memory
c) where windows resumes execution in ram so we can put a
jump there.

But disassembling the CE bootloader is no fun, and I have given up
for now.


So, no good programming, no matter how good it is, will be able to take the first steps of the boot process away from ROM. There *might* or *might not* be a way to trick the machine via software, but so far no one has done it, or proved it's possible.
 Top of the page
Snappy! Page Icon Posted 2005-10-26 9:29 PM
#
Avatar image of Snappy!
H/PC Elder

Posts:
1,712
Location:
New Mexico, US
Status:
cmonex - 2005-10-26 7:08 PM

ProgramSynthesiser - 2005-10-27 2:42 AM

Snappy!, instead of keeping the APM code necessary to resume on the cf, why not just load it to the ram before suspend? It is not large, and the kernel loads itself at startup anyways... But if that happened, considering that the ram is getting power, it would send the signal out the processor, then that to the rest of the motherboard, and BAM! Wakeup sequence. (Correct?)


i agree... or maybe this is not that simple that the "ram is getting power ... " etc. but something like that.. erm Snappy will explain it better

btw, Snappy, your explanation was excellent and easily understood (at least to me), as always!

now can someone show me a linux or similar running from CF and can do *proper* standby? i never saw one for the J720 nor for some other stuff.. not sure about mips netbsd for the z50 NEC 790 etc... Snappy?


ok, I'll reply both in one shot ya?

PS & Cm, Guess the APM could possibly be in the RAM, as long as it is in the bootup image to start with or its loaded later. AFAIK, the only limiting factor here is the RAM, which is used for both dynamic ram and storage. However, that would mean that the APM code have to talk directly to low level devices, something which is not exactly the cleanest way of implementating APM. In such a case, it would still mean having to find out the function calls (most likely to be a push/pop of some registers or values into some mem addresses) for each device and I would think its relatively "easier" to find out the calls for the existing APM firmware that should be sitting in a controller chip somewhere.

With regards to the 2.6 kern, is it working from flashboard or from CF? I got a hunch that the APM driver may need to be tweaked to run off a CF if it is currently on FLASH. Well, apparently. But more importantly, its the wakeup sequence that would need to be tweaked and possibly to implement the APM-in-RAM thingie.

Cmonex, I tried NetBSD 1.6.2 back then and AFAIR, it only shut off the LCD+backlight. It did not do a full suspend. I'll drop a post to the NetBSD folks and see if they got anything going. Or, PS, have u ping the jlime folks yet? They got the 2.6 running right? They may or should have some clues on this. UPDATE: The APM implementation for jlime is doing screen blanking as well, but PS, you may still want to ping them and maybe some info in our discussion may help them jumpstart their efforts.

And yes Cmonex, we agree!
 Top of the page
Snappy! Page Icon Posted 2005-10-26 10:00 PM
#
Avatar image of Snappy!
H/PC Elder

Posts:
1,712
Location:
New Mexico, US
Status:
Quoted from NETBSD hpcsh port newsgroup
Quote

On Fri, Jul 01, 2005 at 15:03:39 +0800, Oleg Gritsak wrote:

> I've been wondering, whats the main reason of suspend/resume absence
> in hpcsh port? Lack of specs or interest? Or maybe some other?

I have some ideas (mostly gleaned from wince), but I have ~zero time
to experiment.

The idea for the *real* suspend is to power down everything, prefetch
the wake-up interrupt handler into CPU cache and point VBR to the
prefetched handler.

SY, Uwe


Maybe this is what's needed?

EDIT:

PS, this is for you and anyone who is chipping into this porting effort ...

http://www.windowsfordevices.com/articles/AT2608778568.html
http://www.intel.com/design/strong/guides/278278.htm

http://www.intel.com/design/strong/manuals/278240.htm -- Read section 4.4 for details on the system registers for turning off devices etc ...

EDIT: More ...

http://appzone.intel.com/pcadn/product.asp?productid=13223323114020...
 Top of the page
« Prev 1 2 3 4 5 6 7 8 9 Next »
Frozen
Jump to forum:
Seconds to generate: 0.265 - Cached queries : 53 - Executed queries : 29