Hi Ron,
I appreciate that this is perhaps not a use you expect Coreboot to be put to, however the following devices all use RDC x86-compatible SoCs and so are theoretically capable of running coreboot + various payloads:
Airlink 101 AR525W (router) Edimax BR-6216Mg (router) Gemtek WRTR-137G (router) Longshine LCS-WR-2114M (router) Sitecom WL-153 (router) Sitecom WL-176 (router) Linksys WRT54GR (router) MGB100 (wireless NAS) Bifferboard (NAS) <--- My main interest
There are many more. They use either R8610, R3211, or S3282 CPUs and have 486SX instruction set, clocked around 133MHz and generally come with 32MB RAM + 1-4MB flash. The chips have OHCI/EHCI controllers and 10/100 ethernet built-in.
I think it makes sense to use the Coreboot payload system (if not Coreboot itself) to extend the bootloaders with extra functionality. One example is USB boot, another is PXE. We might be able to use the payloads as-is for many of these devices.
Kind regards, Biff.
--- On Sun, 17/5/09, ron minnich rminnich@gmail.com wrote:
From: ron minnich rminnich@gmail.com Subject: Re: [coreboot] Minimum RAM requirements for coreboot (under Qemu) To: "bifferos" bifferos@yahoo.co.uk Cc: coreboot@coreboot.org Date: Sunday, 17 May, 2009, 6:42 PM On Sun, May 17, 2009 at 8:04 AM, bifferos bifferos@yahoo.co.uk wrote:
So no surprise that it doesn't work, but how/where do
I change
these values?
It's hard to get a machine with that little memory any more. I think that's the reason for the high number.
I'll take a look today or tomorrow unless someone beats me to it. Sorry for the inconvenience!
ron
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Sun, May 17, 2009 at 12:37 PM, bifferos bifferos@yahoo.co.uk wrote:
I think it makes sense to use the Coreboot payload system (if not Coreboot itself) to extend the bootloaders with extra functionality. One example is USB boot, another is PXE. We might be able to use the payloads as-is for many of these devices.
I agree. I love the embedded world.
OK, let's try to fix this coreboot limitation. We need a trouble ticket for 32MB or less systems.
ron
On Sun, May 17, 2009 at 1:50 PM, ron minnich rminnich@gmail.com wrote:
On Sun, May 17, 2009 at 12:37 PM, bifferos bifferos@yahoo.co.uk wrote: Coreboot seems to require a minimum of 64MB to run, but I would like to port it to a platform > with only 32MB. I noticed in:
targets/emulation/qemu-x86/qemu-x86/normal/crt0.S
This is not the source file. Changes should be made under the src/ directory.
I think it makes sense to use the Coreboot payload system (if not Coreboot itself) to extend the bootloaders with extra functionality. One example is USB boot, another is PXE. We might be able to use the payloads as-is for many of these devices.
I agree. I love the embedded world.
OK, let's try to fix this coreboot limitation. We need a trouble ticket for 32MB or less systems.
This patch lets me boot into filo with down to 8MB of RAM. Coreboot was hardcoded to run at 64MB. I'm not sure that 4MB is the right place to hard code it.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
The problem is that we're going to need a way to *not* hardcode it. 4M is too low because some payloads will run right over it.
In the vm86 mode we put esp at 0xfffc -- i.e. top of page 0. I wonder if we should always have it there. The biggest stack user we have is lzma at around 2kB, but lzma doesn't run until the very end.
ron
The problem is that we're going to need a way to *not* hardcode it. 4M is too low because some payloads will run right over it.
I thought it was OK for payloads to run over coreboot. We don't load them until we're done. Right? What am I missing?
In the vm86 mode we put esp at 0xfffc -- i.e. top of page 0. I wonder if we should always have it there. The biggest stack user we have is lzma at around 2kB, but lzma doesn't run until the very end.
Shouldn't this cause problems with the way we write mptables? If the mptable is too big this would write it over our stack, then zero it back out. My pending patch corrects this, but I didn't know it was an issue.
Thanks, Myles
On Mon, May 18, 2009 at 8:33 AM, Myles Watson mylesgw@gmail.com wrote:
The problem is that we're going to need a way to *not* hardcode it. 4M is too low because some payloads will run right over it.
I thought it was OK for payloads to run over coreboot. We don't load them until we're done. Right? What am I missing?
it's not ok to over-run the stack while loading the payload :-)
Shouldn't this cause problems with the way we write mptables? If the mptable is too big this would write it over our stack, then zero it back out. My pending patch corrects this, but I didn't know it was an issue.
page 0 is getting crowded then.
page 0 is used in vm86 for IDT and stack.
It may be time to make a map. I did a map long ago, but changing circumstances have rendered it obsolete.
ron
it's not ok to over-run the stack while loading the payload :-)
I guess I had assumed before that there was some kind of check that avoided that. It seems like there should be one.
Shouldn't this cause problems with the way we write mptables? If the mptable is too big this would write it over our stack, then zero it back out. My pending patch corrects this, but I didn't know it was an issue.
page 0 is getting crowded then.
page 0 is used in vm86 for IDT and stack.
It may be time to make a map. I did a map long ago, but changing circumstances have rendered it obsolete.
I think that would be good.
Thanks, Myles
On Mon, May 18, 2009 at 9:51 AM, ron minnich rminnich@gmail.com wrote:
On Mon, May 18, 2009 at 8:33 AM, Myles Watson mylesgw@gmail.com wrote:
The problem is that we're going to need a way to *not* hardcode it. 4M is too low because some payloads will run right over it.
I thought it was OK for payloads to run over coreboot. We don't load them until we're done. Right? What am I missing?
it's not ok to over-run the stack while loading the payload :-)
Shouldn't this cause problems with the way we write mptables? If the mptable is too big this would write it over our stack, then zero it back out. My pending patch corrects this, but I didn't know it was an issue.
page 0 is getting crowded then.
page 0 is used in vm86 for IDT and stack.
It may be time to make a map. I did a map long ago, but changing circumstances have rendered it obsolete.
ron
Fat fingers. Should have discarded it, but I sent it instead.
Myles
-
bifferos -
Myles Watson -
ron minnich