Just got an e3 - where do I start
Hello e3 hackers, I just received an e3, which to start with I'd just like to get a kernel to boot on (not quite sure what I'll do with it yet - but that will come later). The guy that gave it to me me said it had been in storage for some time, so fingers crossed that it has not been updated. I don't know yet because I haven't got a compatible PSU yet! If I understand correctly it's the proprietary bootloader on the 128Kb NOR flash that may have been updated making it difficult to hack? Would it be possible to get around this by flashing manually (using an AVR or similar?) If so would anyone be able to supply the correct binary image for the flash? Assuming I can pass this hurdle, what is the shape of linux support for this now? I see from reading the mailing list that the late 2.6 series worked fine... how about 3.x? How about defconfigs with full (or as much as possible) hardware support? I am happy cross compiling a kernel... I guess I can use any old ARM cross compiler? What exactly is the boot process and how does this limit the size of the kernel image? There's a way to get uboot on there - how can I do this? Does the kernel always need to be sent over serial? Sorry for all the questions, but without reading the entire mailing list there doesn't seem to be an easy way to find answers! Thanks, Ed
Hmm... actually programming the AT49LV1024 looks to be a pain in the butt, so I guess if it has PBL 5.1 I am screwed. On Tue, Jun 26, 2012 at 11:45 PM, Edward Robbins <edd.robbins@googlemail.com
wrote:
Hello e3 hackers,
I just received an e3, which to start with I'd just like to get a kernel to boot on (not quite sure what I'll do with it yet - but that will come later).
The guy that gave it to me me said it had been in storage for some time, so fingers crossed that it has not been updated. I don't know yet because I haven't got a compatible PSU yet!
If I understand correctly it's the proprietary bootloader on the 128Kb NOR flash that may have been updated making it difficult to hack? Would it be possible to get around this by flashing manually (using an AVR or similar?) If so would anyone be able to supply the correct binary image for the flash?
Assuming I can pass this hurdle, what is the shape of linux support for this now? I see from reading the mailing list that the late 2.6 series worked fine... how about 3.x? How about defconfigs with full (or as much as possible) hardware support? I am happy cross compiling a kernel... I guess I can use any old ARM cross compiler?
What exactly is the boot process and how does this limit the size of the kernel image? There's a way to get uboot on there - how can I do this? Does the kernel always need to be sent over serial?
Sorry for all the questions, but without reading the entire mailing list there doesn't seem to be an easy way to find answers!
Thanks, Ed
Sorry for 3rd email... Using a 9V supply the emailer appears to start - email and voice lights flash, then after some time the power light comes on when I press power, and camera light comes on when I then press video, but the LCD does not come on. So I suspect that amstrad were being cheap in choosing such a high voltage PSU - because they didn't want to include a backlight inverter to boost the voltage for the LCD backlight. I thus further suspect that I can still talk to the serial port without the full voltage input... so if I build a cable, is there a way I can tell which PBL I have from the serial output? On Wed, Jun 27, 2012 at 12:08 AM, Edward Robbins <edd.robbins@googlemail.com
wrote:
Hmm... actually programming the AT49LV1024 looks to be a pain in the butt, so I guess if it has PBL 5.1 I am screwed.
On Tue, Jun 26, 2012 at 11:45 PM, Edward Robbins < edd.robbins@googlemail.com> wrote:
Hello e3 hackers,
I just received an e3, which to start with I'd just like to get a kernel to boot on (not quite sure what I'll do with it yet - but that will come later).
The guy that gave it to me me said it had been in storage for some time, so fingers crossed that it has not been updated. I don't know yet because I haven't got a compatible PSU yet!
If I understand correctly it's the proprietary bootloader on the 128Kb NOR flash that may have been updated making it difficult to hack? Would it be possible to get around this by flashing manually (using an AVR or similar?) If so would anyone be able to supply the correct binary image for the flash?
Assuming I can pass this hurdle, what is the shape of linux support for this now? I see from reading the mailing list that the late 2.6 series worked fine... how about 3.x? How about defconfigs with full (or as much as possible) hardware support? I am happy cross compiling a kernel... I guess I can use any old ARM cross compiler?
What exactly is the boot process and how does this limit the size of the kernel image? There's a way to get uboot on there - how can I do this? Does the kernel always need to be sent over serial?
Sorry for all the questions, but without reading the entire mailing list there doesn't seem to be an easy way to find answers!
Thanks, Ed
On Wednesday 27 June 2012 at 00:17, Edward Robbins wrote:
Sorry for 3rd email...
Using a 9V supply the emailer appears to start - email and voice lights flash, then after some time the power light comes on when I press power, and camera light comes on when I then press video, but the LCD does not come on. So I suspect that amstrad were being cheap in choosing such a high voltage PSU - because they didn't want to include a backlight inverter to boost the voltage for the LCD backlight. I thus further suspect that I can still talk to the serial port without the full voltage input... so if I build a cable, is there a way I can tell which PBL I have from the serial output?
See the first line of http://www.earth.li/%7Enoodles/files/delta.boot (linked from http://www.earth.li/~noodles/hardware-e3.html). Hope this helps, Antony. -- All generalisations are inaccurate.
On Tue, 26 Jun 2012 23:45:19 Edward Robbins wrote:
Assuming I can pass this hurdle, what is the shape of linux support for this now? I see from reading the mailing list that the late 2.6 series worked fine... how about 3.x?
Hi, This won't help you with your PBL 5.1, but... I'm still trying to do my best to keep this machine supported by subsequent kernel versions, actually running linux-3.4 on mine. Nothing new here since a few releases back, except for smartcard pins available as GPIO, ready for being driven from userspace over the /sys/ API. Perhaps someone ever finds some spare time to write a "driver" for it.
How about defconfigs with full (or as much as possible) hardware support?
The one I posted a few months ago generally still works for me, please examine the list archives.
I am happy cross compiling a kernel... I guess I can use any old ARM cross compiler?
What exactly is the boot process and how does this limit the size of the kernel image? There's a way to get uboot on there - how can I do this? Does the kernel always need to be sent over serial?
I use the old install tools, ramdisk and procedure published in 2006. Works with new kernels built with my defconfig. Thanks, Janusz
Hi, On Wed, Jun 27, 2012 at 09:52:46PM +0200, Janusz Krzysztofik wrote:
I am happy cross compiling a kernel... I guess I can use any old ARM cross compiler?
What exactly is the boot process and how does this limit the size of the kernel image? There's a way to get uboot on there - how can I do this? Does the kernel always need to be sent over serial?
I use the old install tools, ramdisk and procedure published in 2006. Works with new kernels built with my defconfig.
I'm using modified !LDR that loads and boots the kernel and initramfs directly from NAND (they can also be sent over the the serial line). So you don't really need U-boot at all (unless you need some fancy features...). Once you have booted succesfully, you can update the kernel just with nandwrite. You need to send it over the serial only when booting for the first time, or when you have flashed a kernel that does not work. The NAND partitioning is static (hardcoded in the kernel). If I remember correctly, the kernel partition is limited to 3.5 MB. My !LDR loads the initramfs from "file system" partition which is tens of megabytes. In practice these size limitations are not a problem. For the userspace, you can use e.g. the latest Debian rootfs on USB disk. A.
participants (4)
-
Aaro Koskinen -
Antony Stone -
Edward Robbins -
Janusz Krzysztofik