LS-GL Custom Firmware Development
From NAS-Central Buffalo - The Linkstation Wiki
m (→GPL Kernel) |
m |
||
| Line 61: | Line 61: | ||
**YvSInIQopeipx66t_DCdfEvfP47qeVPhNhAuSYmA4 | **YvSInIQopeipx66t_DCdfEvfP47qeVPhNhAuSYmA4 | ||
**IeY8omJwGlGkIbJm2FH_MV4fLsXE8ieu0gNYwE6Ty | **IeY8omJwGlGkIbJm2FH_MV4fLsXE8ieu0gNYwE6Ty | ||
| + | |||
| + | |||
| + | ===Custom Updater=== | ||
| + | See [http://linkstationwiki.net/index.php?title=Category:Opensource_Firmware_Updater Opensource_Firmware_Updater] and [http://forum.linkstationwiki.net/viewtopic.php?f=19&t=1693 LS-GL Custom Updater Thread] for more information. | ||
| + | |||
| + | '''Todo:''' Import information from the forum here. | ||
=Toolchains= | =Toolchains= | ||
| Line 79: | Line 85: | ||
* <big>[[Precompiled C development environment, running on the LS]]</big> | * <big>[[Precompiled C development environment, running on the LS]]</big> | ||
| - | + | =GPL Kernel= | |
| - | + | ||
<big> | <big> | ||
<dpl> | <dpl> | ||
| Line 88: | Line 93: | ||
</big> | </big> | ||
| - | |||
| - | |||
| - | |||
| - | == | + | =Other Development= |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
===User Accomplishments=== | ===User Accomplishments=== | ||
'''Please post accomplishments that don't fit into the above categories here''' | '''Please post accomplishments that don't fit into the above categories here''' | ||
Revision as of 23:19, 31 August 2007
 LS-GL Custom Firmware Development |
|
Please fix and update these sections. Also, please correct any grammar and spelling errors. Thanks -- jonli447
Contents |
Using the Firmware Updater
It is aparent, like all of the Linkstations, that the firmware does not want to update the firmware if the LS-GL reports the same firmware version as the the one to be that's to be sent to the LS-GL (i.e. a modified firmware). The work around is to:
- Add to lsupdater.ini
[SpecialFlags] Debug = 1
- Change in lsupdater.ini
VersionCheck = 1
to
VersionCheck = 0
- Open linkstation_version.txt in any text editor (i.e. vi). Edit either the BOOT=, KERNEL=, INITRD=, or ROOTFS= (this is the main firmware and filesystem) to choose what to update by changing the version to a higher number.
- i.e. by setting rootfs to a higher number, the filesystem will get updated, but uboot, kernel, and initrd won't get updated.
- Steps originally drafted by Georg.
Note: We are not positive if only one segmet (i.e. rootfs) will get updated. This method must be fully tested to find this out.
jonli, should I move the following more technical part about Erics excellent work into a separate section? - Georg
Updater Specifications
- As EricC documented on the LS-GL side clientUtil_server handles the update process and replies to various "ACP"-Commands, which are similar for the LS-GL and the Kurobox:
- LSP Commands
- 8020 ACP_Discover
- 8080 ACP_FIRMUP2
- 80A0 ACP_?? Possible Password?
- 8A10 ACP_CMD
- 8B10 ACP_?? Sent after 8080 and contains the filename. TCP File transfer starts after reply
- 8B20 ACP_?? Sent after TCP file transfer
- LSP Responses
- C020 ACP_Discover_Reply
- COAO Reply of 80A0
- CA10 ACP_CMD_Reply
- CB10 ACP_??_Reply 8B10
- CB20 ACP_??_Reply 8B20
- CB21 Sent after CB20. Same format with data changes Update complete?
- KuroBox Commands
- 8020 ACP_Discover
- 8070 ACP_FIRMUP_END
- 8080 ACP_FIRMUP2
- 8090 ACP_Info_HDD
- 8A10 ACP_CMD
- KuroBox Responses
- C020 ACP_Discover_Reply
- Looking at the command word
- Bit 15 = 1
- Bit 14 is 0 for command and 1 for reply
- Bits 11 to 8 appear to be the command class
- Bits 7 to 4 appear to be the command in the class.
- Bits 3 to 0 appear to be a sequence number in the response.
- The updater on the LS-GL receives ziped images and tries to unzip them by testing for the following passwords
- 1NIf_2yUOlRDpYZUVNqboRpMBoZwT4PzoUvOPUp6l
- aAhvlM1Yp7_2VSm6BhgkmTOrCN1JyE0C5Q6cB3oBB
- YvSInIQopeipx66t_DCdfEvfP47qeVPhNhAuSYmA4
- IeY8omJwGlGkIbJm2FH_MV4fLsXE8ieu0gNYwE6Ty
Custom Updater
See Opensource_Firmware_Updater and LS-GL Custom Updater Thread for more information.
Todo: Import information from the forum here.
Toolchains
Opened Firmwares
Telnet enabled firmware
Jtymod
Open Stock Firmware
FreeLink
Development Tools
GPL Kernel
Other Development
User Accomplishments
Please post accomplishments that don't fit into the above categories here
- jtymod got ssh up and running, enhanced the webinterfaces sp you can controll telnet + ssh + a mediaserver
- chroot Arm Build Environment by armstation
Why: To not fill up LinkStation's system partition & To test toolchains and building programs without risk of breaking anything
1) Create a chroot somewhere outside of the LinkStation system partition.
mkdir /mnt/disk1/share/arm-tools
2) Transfer entire Linkstation system to build directory.
cd / for d in `ls |grep -v dev |grep -v proc|grep -v mnt` do tar -cvf /mnt/disk1/share/arm-tools/$d.tar $d done
3) Unpack the system directories.
cd /mnt/disk1/share/arm-tools for f in *.tar do tar -xvf $f done
4) Download jonli447's excellent arm-tools and copy them into /mnt/disk1/share/arm-tools/ then Gunzip & Untar the arm tools
tar -xvzf arm-tools-0_16-3.tgz
5) Mount special files in chroot environment (thanks Zoolook)
mount -t proc none /mnt/disk1/share/arm-tools/proc mount -o bind /dev /mnt/disk1/share/arm-tools/dev
6) Create /opt directory in chroot
mkdir /mnt/disk1/share/arm-tools/opt
7) Create symbolic link from chrooted /opt to system /opt
ln -s /mnt/disk1/share/arm-tools/opt /opt
8) chroot into development environment.
chroot /mnt/disk1/share/arm-tools /bin/sh
That's it, now everyting compiled and installed to /opt from chroot will be available from the main Linkstation system without adding any files to the system partition besides 1 symbolic link.
Related Forum Topics
- Telnet Access
- Native Toolchain
- Codesourcery Toolchain
- Custom Updater
- Kernel Development
- Debian for LS-GL
- OpenLink for LS-GL Debate Poll
- Optware IPKG Feed Poll
Todo: Add information to above sections.
