|
bytespider
|
 |
« on: November 07, 2007, 11:27:05 AM » |
|
Hey all,
Dont know how many of you have done this, but I've opened communications with one of the firmware's developers - Lily.
So please if there are any questions to ask on the development of this firmware, post and i will ask Lily.
So far Lily told me that all the modifications to the kernel were to enable the drivers the device needs.
However i have diff'd the modded kernel against a clean kernel and notice there are a few added machine code functions that include halt the device and flash the leds.
Hopefully with a developer on our side we progress.
PS. Tried Schufti's firmware last night - loads of new stuff in there, so would apreciate if you could explain what you did (removing rc.bridge and using the standard rcS is a good idea)
Cheers guys.
|
|
|
|
|
Logged
|
|
|
|
|
schufti
|
 |
« Reply #1 on: November 07, 2007, 20:40:26 PM » |
|
Hi bytespider,
let's hope that Lily is more talkative to you. I had quite a few email contacts, but she didn't give away any details on the AMIT specific binaries, nor any hint on how to access the settings/ GUI fs. I really would like to get some details on that topic! Or a complete GPL-package for the MGB111. Or some details on the checksumming, etc....
The toolchain is badly configured, so as that some parts aren't compiled with the intended options or are compiled even with/relying on the host system and only working as root!!! Even the packages makefiles are crippled to a point where e.g. a make clean doesn't remove files and you never get the executable build anew.
The changes to the kernel are a disgrace to any embedded system. They are the best example for how not to do it, even if you are on tight budget/schedule. e.g.t the rtc could be solved in a compatible way with only a few additional lines of code [(c) by laxan]. The way they did the rootfilesystem is horrible and wastes RAM, the way to activate the recovery loader is the largest piece of sh.. I ever saw, etc....
undocumented changes to the kernel:
a) essential, code to branch to the recovery loader (really, really stupid idea!!!!!)
b) good to have: code for correct resetting CPU (but not needed again in BusyBox!)
c) good to have: code to write-enable FLASH
d) unnecessary: rtc (better to have real driver)
e) unnecessary: changes to usb-system for hotplugging (why not use standards?)
f) unnecessary: changes to usb for USB-LED on/off (should be in hotplug script/binary)
g) more unnecessary changes for chip/devices not even present in MGB100
....
so the best thing would be to start from scratch and get a sound basis for something reliable and well maintained as OpenWRT (allthough the MGB100 is no router), what I tried to initialize by collecting all the details on the hw, getting RedBoot to run and give comfort to the curious with providing the jtag solution.
Some guy (laxan) started to adapt the 2.6 kernel based on a compatible FLASH partiton, but at the moment he is stuck with the WLAN not operating when booted from RB.
The second best thing is what I can do: help the existing FW to overcome it's worst shortcomings.
shufti
p.s.: the changes in my fw are summarized in the 1st posting of the "new FW image" thread
|
|
|
|
|
Logged
|
I won't answer posts or PMs about repair/recovery after bad flash until proven that the wiki was read and followed! find all my MGB100 files here, pass: mgb100 |
|
|
|
bytespider
|
|
« Reply #2 on: November 08, 2007, 10:04:35 AM » |
|
Schufti, The MGB111 is the same as the WMU-6500FS and the GPL code can be downloaded from AirLive http://www.airlive.com/support/gpl_code/GPL_WMU-6500.zipI attempted to ask about how led and the amit_* binaries work, but hit a very (overly) protective wall. I too was hoping that we could re build the firmware from scratch, and have been collecting information. Have you tied the two c files i posted when in the topic about when i recovered my mgb100 last? They build split and make binary code. The splitbin one seems to split the bin in to the parts as shown in a memory map of the binary, ie the initrd is in part 3 if i remeber correctly, and that was a simple gzipped archive. Maybe the other gui fs is too, but on a different part of the split bin? When you load up redboot do we loose compatablility with the original firmware? This is fine as long as i can still get in via ethernet and not serial - my soldering skills arnt that great! Cheers, look forward to more info soon. |
|
|
|
|
Logged
|
|
|
|
|
schufti
|
|
« Reply #3 on: November 08, 2007, 13:57:44 PM » |
|
Hi,
I know the split and make sw; it is - like the rtc driver - by laxan. But I don't need/use it. You can read in the wiki page I maintain for the MGB100-dangerous stuff that I perfectly know where the GUI-fs and the settings are, but without info on the access mechanism it could only be "hacked" via hexeditor - what I really don't intend to do.
Yes, you loose compatibility with RB. I tried to get it as small as possible, but couldn't fit it into the available 64kB, so the settings and gui space is overwritten. laxan provides a hacked RB that invokes telnet via the buttons.
Trying to mess with root-fs without serial console is a NONO. Trying to mess with kernel or RB without jtag is .... stupid.
schufti
p.s.: I know that MGB111 (or PE-4088) is the same as WMU-6500 but I also know that is the only GPL-packet on the net and that it is incomplete!
|
|
|
|
« Last Edit: November 08, 2007, 21:57:53 PM by schufti »
|
Logged
|
I won't answer posts or PMs about repair/recovery after bad flash until proven that the wiki was read and followed! find all my MGB100 files here, pass: mgb100 |
|
|
|
bytespider
|
|
« Reply #4 on: November 09, 2007, 09:57:04 AM » |
|
Schufti, I didn't mean to offend you, I dont know the full extent of you knowledge. Lily informs me You will need the HTTP daemon to do the GPL upgrade unless you know how to re-program the flash ROM,
so DO NOT disable this daemon. This seems to be true as httpd seems to be one of the main control binaries, and we are unable to kill it as init just reloads it at the next opportunity. She will not tell me about how to read and write the config from flash. |
|
|
|
|
Logged
|
|
|
|
|
bytespider
|
|
« Reply #5 on: November 09, 2007, 11:17:54 AM » |
|
Latest from lily on the Wireless drivers and the MAC. For wireless driver, it is non-GPL version, we only released binary module. You could change the driver if you can get it from some other sources. But, sorry, I really don't remember that if we modified anything or not. Has any one tried to rebuild the wireless driver? from sources found outside of the GPL packet? |
|
|
|
|
Logged
|
|
|
|
|
schufti
|
|
« Reply #6 on: November 09, 2007, 16:54:34 PM » |
|
Hi,
I'm not offended, I only wanted to save you from barking up the same tree by reading the wiki and the page where you got the split/make sources, to get a good impression about the cumulative knowledge and be able to see where information is missing (but not generally needed most).
The client part of WLAN drivers is in any GPL-packet, the AP part leaked through one of them.
The warning about playing around (even with unaltered sources) without serial/jtag is serious advice from people hit by doom after a "minor" change only. With RB even a typo can leave your device "unrecoverable".
schufti
|
|
|
|
|
Logged
|
I won't answer posts or PMs about repair/recovery after bad flash until proven that the wiki was read and followed! find all my MGB100 files here, pass: mgb100 |
|
|
|
bytespider
|
|
« Reply #7 on: November 09, 2007, 17:41:13 PM » |
|
Lily seems very keen to develop the firmware, but seems only on an application front. I.E. what can this device do - Media server / FTP server / BT downloader.
Im tring to get into jtag - life would be easier if cables came pre-fabricated and fairly cheeply.
As soon as I have one I can start tinkering bit in the meantime....
Schufti, when you are developing are you aiming to keep stock firmware compatability or rewrite?
I've found patches that enable RDC changes in the kernel if anyone is interested?
So far it sounds like redboot is pretty much done for this platform, i guess a working kernel and initrd are needed next?
What else is needed to get a minimal system that isnt stock compatible? other than redboot
I dont care about any of the amit binaries - or reading and writing from the flash.
Cheers
p.s. These boards seem extremely quiet lately! Have people gotten bored?
|
|
|
|
|
Logged
|
|
|
|
|
schufti
|
|
« Reply #8 on: November 09, 2007, 18:22:20 PM » |
|
Hi,
as I might have written somewhere in this forum allready, now that RB is working, the fastest solution to a working system would be adapting OpenWRT-Kamikaze. There is allready a branch for RDC, so only specifics like WLAN, RTC, Buttons&LEDs are missing but drivers are allready availlable.
Downside is, with RB WLAN needs some more in depth analysis.
schufti
|
|
|
|
|
Logged
|
I won't answer posts or PMs about repair/recovery after bad flash until proven that the wiki was read and followed! find all my MGB100 files here, pass: mgb100 |
|
|
|
macsat
|
|
« Reply #9 on: November 10, 2007, 09:03:58 AM » |
|
As for OpenWrt Kamikaze - If one of you are going down that road, a good idea would probably be to contact Kaloz over at OpenWrt. His email is kaloz@openwrt.orgI think he would find this work interesting, and would like to help with whatever info you might need. |
|
|
|
|
Logged
|
|
|
|
|
pagano
|
|
« Reply #10 on: November 12, 2007, 19:12:08 PM » |
|
Ask Lily about the posibility of load kernel from HDD at boot time instead FLASH image.
|
|
|
|
|
Logged
|
|
|
|
|
bytespider
|
|
« Reply #11 on: November 12, 2007, 19:50:30 PM » |
|
@pagano I've asked but I'm betting the answer is no - or why do you want to do this!  Lily isn't THAT helpful, unless I give ideas to advance the amit firmware. @macsat Thanks for the tip for contacting OpenWRT - so far no response |
|
|
|
|
Logged
|
|
|
|
|
bytespider
|
|
« Reply #12 on: November 13, 2007, 10:41:06 AM » |
|
@pagano Lily's response to the kernel mod.
Sorry, it is not possible, or I should say, it is not easy to do.
The boot loader is desinged to load kernel from Flash ROM.
But, to do anything on the boot loader is dangerous.
If you know how to modify, you could do it in linux kernel.
Linux kernel start up from Setup.S, an assembly file.
But, it is also dangerous.
Not quite sure what Lily is on about modding the Setup.S file but this feels like its part of the init process? |
|
|
|
|
Logged
|
|
|
|
|
schufti
|
|
« Reply #13 on: November 13, 2007, 11:16:28 AM » |
|
what Lily is saying is that:
a) the orig. Bootloader (RDC-BIOS) is minimalistic and not user configurable; only able to start the kernel (with ramdisk) from a given, fixed address in flash. They (AMIT) didn't even hack the emergency loader in this BIOS, instead it is called from the kernel-init (stupid, even worse than M$)
b) that the only way would be to modify the kernel to load an other kernel (e.g. kexec, monte)
c) that this could be done e.g. in the kernel-init (Setup.S), too.
d) finally: that messing with Setup.S is very dangerous, because the exit to the emergency-loader is situated in this part of code. (if this stops working, you are left with a brick - only jtag)
schufti
|
|
|
|
|
Logged
|
I won't answer posts or PMs about repair/recovery after bad flash until proven that the wiki was read and followed! find all my MGB100 files here, pass: mgb100 |
|
|
|
pagano
|
|
« Reply #14 on: November 13, 2007, 12:04:01 PM » |
|
If you know how to modify, you could do it in linux kernel.
Linux kernel start up from Setup.S, an assembly file.
But, it is also dangerous.
Good idea. Tests can be done safely adding a "check single button" function for load and run alternate kernel after the firmware recovery function in Setup.S (check for both buttons). System is in real mode at boot time and we can skip the kexec patches. ...
/*
* added by lily@amit.com.tw for recovery mode
*
* NOTE!!! Please DO NOT modify this section, unless you know what you are doing!!!!
*
*/
...
not_pressed:
#if defined(_MGB100)
mov $0x0cf8, %dx
mov $0x8000384C, %eax
outl %eax, %dx
mov $0x0cfc, %dx
inl %dx, %eax
orl $0x03, %eax
outl %eax, %dx
inl %dx, %eax
andl $0x01, %eax /* 3 is two buttons...*/
cmpl $0x01, %eax /* is 1 the alone button check? */
jz not_pressed2
#endif
LOAD AND RUN KERNEL like monte and kexec does. (Assembler)
not_pressed2:
#if defined(_MGB100)
/* turn off LED */
mov $0x0cf8, %dx
...
...
The recovery system can be requested before if new changes are wrong... |
|
|
|
« Last Edit: November 13, 2007, 13:08:50 PM by pagano »
|
Logged
|
|
|
|
|
