Hi,
BIOSes is an area where accessibility is approximately non-existent. Asking vendors to support hardware speech syntheses and braille devices is quite dreamwork. I tried to convince accessibility people to release basic drivers with BSD licenses so that vendors might integrate them, but they just refused that, arguing that vendors will not make any effort to integrate them, and there will always be bugs (which are hard to debug/fix/integrate/... with vendor BIOSes).
LinuxBios, however, can be a great opportunity to have an accessible BIOS.
So what can be done? If I understood well, LinuxBios is a linux kernel -based bios. Does that mean that it has the notion of process, or does it run only in kernel mode? (which is sufficient for taking advantage of linux drivers).
Samuel
* Samuel Thibault samuel.thibault@ens-lyon.org [060703 00:06]:
BIOSes is an area where accessibility is approximately non-existent. Asking vendors to support hardware speech syntheses and braille devices is quite dreamwork. I tried to convince accessibility people to release basic drivers with BSD licenses so that vendors might integrate them, but they just refused that, arguing that vendors will not make any effort to integrate them, and there will always be bugs
Maybe this code could be encapsulated, similar to how VGA bios or network boot is handled. On the other hand, this would cut off quite some of the bringup from "visibility"
LinuxBios, however, can be a great opportunity to have an accessible BIOS.
So what can be done? If I understood well, LinuxBios is a linux kernel -based bios. Does that mean that it has the notion of process, or does it run only in kernel mode? (which is sufficient for taking advantage of linux drivers).
LinuxBIOS initializes the machine just far enough so that it can run a Linux kernel from flash memory, hence the name. This in-flash Linux can run normal userspace programs as well as load another kernel from a hard disk or any other supported medium.
usually we can say: the main information exchange with LinuxBIOS (before the kernel is started) is not via VGA but via serial, which i believe is in theory usable with a braille terminal connected to another machine. (Is this correct?)
The interaction part is all happening while Linux is loaded (ie. from flash) so we could use a local braille terminal at this point by using all the Linux utilities.
One question is: how big is the Linux code to support one/some/many/all braille terminals and can we fit this in a 512kB/1MB flash part. The answer mostly depends on your needs.
Regards Stefan
Hi,
Great to have so fast a reply :)
Stefan Reinauer, le Mon 03 Jul 2006 01:11:05 +0200, a écrit :
- Samuel Thibault samuel.thibault@ens-lyon.org [060703 00:06]:
BIOSes is an area where accessibility is approximately non-existent. Asking vendors to support hardware speech syntheses and braille devices is quite dreamwork. I tried to convince accessibility people to release basic drivers with BSD licenses so that vendors might integrate them, but they just refused that, arguing that vendors will not make any effort to integrate them, and there will always be bugs
Maybe this code could be encapsulated, similar to how VGA bios or network boot is handled.
Indeed, except that it relies on serial or USB support, which might not be easy to ship in a so encapsulated way.
On the other hand, this would cut off quite some of the bringup from "visibility"
I'm sorry, my poor english couldn't understand that :)
LinuxBios, however, can be a great opportunity to have an accessible BIOS.
So what can be done? If I understood well, LinuxBios is a linux kernel -based bios. Does that mean that it has the notion of process, or does it run only in kernel mode? (which is sufficient for taking advantage of linux drivers).
LinuxBIOS initializes the machine just far enough so that it can run a Linux kernel from flash memory, hence the name. This in-flash Linux can run normal userspace programs as well as load another kernel from a hard disk or any other supported medium.
Oh, great. That means that we can run the usual screen reader called brltty, or any other such reader.
usually we can say: the main information exchange with LinuxBIOS (before the kernel is started) is not via VGA but via serial, which i believe is in theory usable with a braille terminal connected to another machine. (Is this correct?)
Yes. Minicom is quite accessible, so that's fine.
The interaction part is all happening while Linux is loaded (ie. from flash) so we could use a local braille terminal at this point by using all the Linux utilities.
Yup.
One question is: how big is the Linux code to support one/some/many/all braille terminals and can we fit this in a 512kB/1MB flash part. The answer mostly depends on your needs.
Devices usually depend on serial or USB support, plus the /dev/vcsa interface for reading the console's content.
Samuel
* Samuel Thibault samuel.thibault@ens-lyon.org [060703 01:26]:
Maybe this code could be encapsulated, similar to how VGA bios or network boot is handled.
Indeed, except that it relies on serial or USB support, which might not be easy to ship in a so encapsulated way.
Serial support is easy. USB is more of a problem as it needs a complete usb stack at bios time.
On the other hand, this would cut off quite some of the bringup from "visibility"
I'm sorry, my poor english couldn't understand that :)
Sorry for the confusion. Transforming sentences from german to english to french is sometimes hard :)
What I was trying to say is: If you plug it in all code that is executed before the plugin gets started gets lost.
Devices usually depend on serial or USB support, plus the /dev/vcsa interface for reading the console's content.
mostly due to the fact that new braille terminals mostly use usb rather than serial this would be the way to go, trying to get the required system as small as possible (ie uclibc, minimal kernel etc)
Stefan Reinauer, le Mon 03 Jul 2006 01:41:49 +0200, a écrit :
- Samuel Thibault samuel.thibault@ens-lyon.org [060703 01:26]:
On the other hand, this would cut off quite some of the bringup from "visibility"
I'm sorry, my poor english couldn't understand that :)
Sorry for the confusion. Transforming sentences from german to english to french is sometimes hard :)
What I was trying to say is: If you plug it in all code that is executed before the plugin gets started gets lost.
Ok, makes sense. We indeed would like output as early as possible.
Devices usually depend on serial or USB support, plus the /dev/vcsa interface for reading the console's content.
mostly due to the fact that new braille terminals mostly use usb rather than serial
Indeed. There are some hardware speech synthesis too, but they often only require i/o ports access, serial access, or maybe parallel port access.
Samuel
Stefan Reinauer wrote:
- Samuel Thibault samuel.thibault@ens-lyon.org [060703 01:26]:
Maybe this code could be encapsulated, similar to how VGA bios or network boot is handled.
Indeed, except that it relies on serial or USB support, which might not be easy to ship in a so encapsulated way.
Serial support is easy. USB is more of a problem as it needs a complete usb stack at bios time.
I remember discussing with the LinuxBIOS list a year or two ago, the issue of what to do when chipsets drop having any serial ports.
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
-Bari
two ways 1. Eric said that the EHCI that may not need buffer for some debug function. 2. use cpu cache for ohci or uhci buffer for packet.
YH
On 7/2/06, Bari Ari bari@onelabs.com wrote:
Stefan Reinauer wrote:
- Samuel Thibault samuel.thibault@ens-lyon.org [060703 01:26]:
Maybe this code could be encapsulated, similar to how VGA bios or network boot is handled.
Indeed, except that it relies on serial or USB support, which might not be easy to ship in a so encapsulated way.
Serial support is easy. USB is more of a problem as it needs a complete usb stack at bios time.
I remember discussing with the LinuxBIOS list a year or two ago, the issue of what to do when chipsets drop having any serial ports.
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
-Bari
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
* yhlu yinghailu@gmail.com [060703 03:31]:
- use cpu cache for ohci or uhci buffer for packet.
Don't they circumvent the CPU to access the memory?
Stefan Reinauer stepan@coresystems.de writes:
- yhlu yinghailu@gmail.com [060703 03:31]:
- use cpu cache for ohci or uhci buffer for packet.
Don't they circumvent the CPU to access the memory?
Depends on the cpu. As I recall Intel cpus flush data to memory for all of their cache coherence, so I don't think it would work there. I think AMD is some better in this regard, but I would be surprised if it worked. It makes sense to research it though.
So if we have to use DMA it looks like we are out of luck until after memory is initialized. Ouch!.
So sending some really simply usb commands out the EHCI debug port looks really interesting. If that works it is also very interesting for debugging kernels on modern hardware as well.
Eric
* Bari Ari bari@onelabs.com [060703 02:40]:
I remember discussing with the LinuxBIOS list a year or two ago, the issue of what to do when chipsets drop having any serial ports.
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
What ports do they have? Any JTAG or similar?
Maybe its possible to hack up a "dumb serial over usb" driver that does not offer a protocol stack but simply pushes characters?
Stefan Reinauer wrote:
- Bari Ari bari@onelabs.com [060703 02:40]:
I remember discussing with the LinuxBIOS list a year or two ago, the issue of what to do when chipsets drop having any serial ports.
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
What ports do they have? Any JTAG or similar?
JTAG/HDT, USB, and PCIe.
-Bari
Bari Ari wrote:
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
I would most rather do what we're doing on OLPC: linux in flash, since linux works well with usb.
ron
* Ronald G Minnich rminnich@lanl.gov [060703 16:07]:
Bari Ari wrote:
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
I would most rather do what we're doing on OLPC: linux in flash, since linux works well with usb.
No doubt.
But it does not solve the solution of the "how do we do ram bringup without serial interface", so we need to think of something in this area.
* HDT / JTAG * dumb buffer free usb serial support * (bonkers) building a bios savior with a writeable and remote readable part which allows us to have a "serial console" with simple memory writes.
Stefan
Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [060703 16:07]:
Bari Ari wrote:
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
I would most rather do what we're doing on OLPC: linux in flash, since linux works well with usb.
No doubt.
But it does not solve the solution of the "how do we do ram bringup without serial interface", so we need to think of something in this area.
- HDT / JTAG
best.
- dumb buffer free usb serial support
yes, but ... how hard is that? From what I have seen, hard, but I guess we have to do it.
The problem with usb serial is that so much has to work correctly before it will work at all. IIRC some of the dongles require you to download a program into them before the work. Once we lose serial, we lost the ability to put out diag info with a simple outb to a port. We have to partake of the USB train wreck to get anything out at all.
ron
Ronald G Minnich wrote:
Bari Ari wrote:
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
I would most rather do what we're doing on OLPC: linux in flash, since linux works well with usb.
That is the plan, LinuxBIOS in Flash. And since we're all AMD based, RAM setup is easier.
While I was at Computex Taipei last month everyone at the Intel suite seemed baffled that Intel would turn down so much business in embedded by not supporting LinuxBIOS. Then again Intel has made a few bad turns the last few years.
-Bari
Bari Ari wrote:
While I was at Computex Taipei last month everyone at the Intel suite seemed baffled that Intel would turn down so much business in embedded by not supporting LinuxBIOS. Then again Intel has made a few bad turns the last few years.
yes, it is very puzzling. I wish it could get fixed.
ron
Ronald G Minnich wrote:
Bari Ari wrote:
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
I would most rather do what we're doing on OLPC: linux in flash, since linux works well with usb.
Linux kernel in flash for real fast power-on to boot is the plan. "Instant on" for set-top-box and thin/media client applications. No legacy ports: serial, parallel, PATA, PS2.
-Bari
so you will not get debug info on linuxbios stage. and some later stge of Linux kernel you will get some out put even later than from vga console.
YH
On 7/3/06, Ronald G Minnich rminnich@lanl.gov wrote:
Bari Ari wrote:
We are currently working on mainboard designs that will not have any serial ports with chipsets that don't have any serial ports. What did we decide to do with LinuxBIOS, since the future is now?
I would most rather do what we're doing on OLPC: linux in flash, since linux works well with usb.
ron
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
yhlu wrote:
so you will not get debug info on linuxbios stage. and some later stge of Linux kernel you will get some out put even later than from vga console.
yes, but ... that's how it goes. Very few people want to see linuxbios anyway.
Many years ago I did an experiment, and was able to set things up so that linuxbios log buffer was picked up by the kernel, so you could do a dmesg and see linuxbios messages. I think this might be useful to revive.
I just don't see us putting a fully capable usb stack into linuxbios, it will not work as well as the linux usb stack.
ron
hi Stefan und Samuel,
the problem with the braille support in bios is that the modern PCs don't have a seriel-port maybe an on-board pin-connector
that's why more an more braille-display manufactories switch to usb-connection so, we need usb-serial-converter support in bios another problem is that the braille-display-protocoll is not a standard each manufactory use their own protocoll in some cases the protocoll is dependent on the model
and they also use different usb-serial-converters
the braille-driver is only one part a second part is a very small and simple screenrading mechainism to genrate a proper output
I think first it would be helpful to have bios access from the console with a small tool to adjust bios settings like boot from CD or enable/disable hardware
maybe there is already a way to do this
best regards
marco
On Mon, 3 Jul 2006, Stefan Reinauer wrote:
- Samuel Thibault samuel.thibault@ens-lyon.org [060703 00:06]:
BIOSes is an area where accessibility is approximately non-existent. Asking vendors to support hardware speech syntheses and braille devices is quite dreamwork. I tried to convince accessibility people to release basic drivers with BSD licenses so that vendors might integrate them, but they just refused that, arguing that vendors will not make any effort to integrate them, and there will always be bugs
Maybe this code could be encapsulated, similar to how VGA bios or network boot is handled. On the other hand, this would cut off quite some of the bringup from "visibility"
LinuxBios, however, can be a great opportunity to have an accessible BIOS.
So what can be done? If I understood well, LinuxBios is a linux kernel -based bios. Does that mean that it has the notion of process, or does it run only in kernel mode? (which is sufficient for taking advantage of linux drivers).
LinuxBIOS initializes the machine just far enough so that it can run a Linux kernel from flash memory, hence the name. This in-flash Linux can run normal userspace programs as well as load another kernel from a hard disk or any other supported medium.
usually we can say: the main information exchange with LinuxBIOS (before the kernel is started) is not via VGA but via serial, which i believe is in theory usable with a braille terminal connected to another machine. (Is this correct?)
The interaction part is all happening while Linux is loaded (ie. from flash) so we could use a local braille terminal at this point by using all the Linux utilities.
One question is: how big is the Linux code to support one/some/many/all braille terminals and can we fit this in a 512kB/1MB flash part. The answer mostly depends on your needs.
Regards Stefan
-- coresystems GmbH o Brahmsstr. 16 o D-79104 Freiburg i. Br. Tel.: +49 761 7668825 o Fax: +49 761 7664613 Email: info@coresystems.de o http://www.coresystems.de/
------------------------------------------------------------ Marco Skambraks, Product Manager SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053-0 Fax: +49 (0) 911 74053-483 marco.skambraks@suse.com ------------------------------------------------------------ ** life is hard and then you die **
Marco Skambraks, le Mon 03 Jul 2006 12:56:56 +0200, a écrit :
another problem is that the braille-display-protocoll is not a standard each manufactory use their own protocoll in some cases the protocoll is dependent on the model
and they also use different usb-serial-converters
the braille-driver is only one part a second part is a very small and simple screenrading mechainism to genrate a proper output
Indeed, but LinuxBIOS is a way to boot a linux kernel right from the mainboard, so you can then run usual screen readers (brltty/suseb/...).
I think first it would be helpful to have bios access from the console with a small tool to adjust bios settings like boot from CD or enable/disable hardware
maybe there is already a way to do this
This is another interesting approach indeed, which might interest many more people.
Samuel
Samuel Thibault wrote:
I think first it would be helpful to have bios access from the console with a small tool to adjust bios settings like boot from CD or enable/disable hardware
maybe there is already a way to do this
This is another interesting approach indeed, which might interest many more people.
Samuel
I think the right way to do this, as always, is to make linux the thing you interface with at power-on or reset, and you load Linux from FLASH from. Most BIOSes are bad OS designs -- for the latest bad design, read the EFI manual, and reflect on the fact that it does far less than Unix V6 did 30 years ago, and somehow manages to do a lot less in 1400 pages of documentation. But with Linux as the BIOS, you've got a good OS as your bios, and you can do all kinds of neat things.
ron
-
Bari Ari -
ebiederman＠lnxi.com -
Marco Skambraks -
Ronald G Minnich -
Samuel Thibault -
Stefan Reinauer -
yhlu