redboot

[lenker]

Hi,

hat jemand eine gute seite wo man was ueber redboot lesen kann?
(speziell suche ich info's man den ip stack in betrieb bekommt, im moment schaff ich noch nichtmal ein einziges ping *g*)
und xmodem zum recovern is echt nervig...

Danke,
--Roland

 

[foschi]

Starte mal hier: http://sourceware.org/redboot/

RedBoot Users Guide

 

[lenker]

schade
so wie dlink den router gebaut hat, wird das niemals funktionieren (zumindest nicht, solange nix an herta gemacht wurde)

RedBoot network gateway
RedBoot cannot communicate with machines on different subnets because it does not support routing. It always assumes that it can get to an address directly, therefore it always tries to ARP and then send packets directly to that unit. This means that whatever it talks to must be on the same subnet. If you need to talk to a host on a different subnet (even if it's on the same ‘wire’), you need to go through an ARP proxy, providing that there is a Linux box connected to the network which is able to route to the TFTP server. For example: /proc/sys/net/ipv4/conf/<interface>/proxy_arp where <interface>should be replaced with whichever network interface is directly connected to the board.

 

[hehol]

schade
so wie dlink den router gebaut hat, wird das niemals funktionieren (zumindest nicht, solange nix an herta gemacht wurde)

Der Rechner für das Update und Horst sind im selben Subnetz, nämlich am Switch von Herta angeschlossen. Wenn der Update-Rechner eine IP-Adresse 192.0.2.x hätte, dann könnte das funktionieren.

Anscheinend liegt das Problem der fehlenden Netzwerkanbindung in Redboot bei der Horstbox woanders: der Netzwerktreiber fehlt. Es gibt im Sourcecode zum Redboot Versuche, die Netzwerkschnittstelle, die die XScale-Plattform anbietet, zu nutzen, aber das wurde nicht zu Ende programmiert. Von Intels Entwicklungsplattform kann man leider auch nichts kopieren, weil Intel statt der Onboard-Schnittstelle einfach eine Etherpro PCI-Netzwerkkarte verwendet :-( Grundsätzlich sollte der Redboot-Code vom Netgear WG302 einen passenden Treiber enthalten, weil Netgear die selbe Plattform verwendet und Recovery via TFTP anbietet. Ich habe den Redboot-Sourcecode aber auf der Opensource-Website von Netgear nirgendwo gefunden.

Da die Plattform Horstbox an sich läuft, lohnt es sich IMHO jetzt auch nicht mehr, den Ethernet-Treiber im Redboot zu Ende zu programmieren.

Henning

 

[lenker]

wenn ich mir die redboot meldungen so ansehen:

Trying NPE-B...no PHY found
Trying NPE-C...success. Using NPE-C with PHY 1.

und meine eigenen probleme mit dem gpl treiber da mit rein nehme, dann ist u.u. das problem von redboot nur die nicht standartmaessige anordnungen der PHY's zu NPE's:

ixp4xx_mac driver 0.3.1: eth0 on NPE-B with PHY[1] initialized
ixp4xx_mac driver 0.3.1: eth1 on NPE-C with PHY[0] initialized

wenn ich dann noch in:
V-Unstable-Patched/redboot/redboot/redboot.patch
schaue:

#ifdef CYGPKG_DEVS_ETH_ARM_IXDPG425_NPE_ETH0
#define CYGSEM_INTEL_NPE_USE_ETH0
#define CYGNUM_ETH0_ETH_ID IX_ETH_PORT_1
-#define CYGNUM_ETH0_PHY_NO 5
+#define CYGNUM_ETH0_PHY_NO 0
#define CYGDAT_NPE_ETH0_NAME CYGDAT_DEVS_ETH_ARM_IXDPG425_NPE_ETH0_NAME
#endif

#ifdef CYGPKG_DEVS_ETH_ARM_IXDPG425_NPE_ETH1
#define CYGSEM_INTEL_NPE_USE_ETH1
#define CYGNUM_ETH1_ETH_ID IX_ETH_PORT_2
-#define CYGNUM_ETH1_PHY_NO 4
+#define CYGNUM_ETH1_PHY_NO 1
#define CYGDAT_NPE_ETH1_NAME CYGDAT_DEVS_ETH_ARM_IXDPG425_NPE_ETH1_NAME
#endif

dann sieht dieser patch fuer mich einfach falsch aus. PHY 0 und 1 muessten vertauscht werden.

Allerdings ist mir privat das risiko zu hoch ein neues redboot zu schreiben, und die kiste damit u.u. hinzurichten.

Gruss,
Roland

 

[foschi]

Och, die bekommen wir schon wieder ans laufen, solltest Du Dir die "geschossen" haben

 

[lenker]

mit equipment fuer den JTAG port sicherlich, aber das hab ich nicht.
und sowas zu fixen ist meiner meinung nach verantwortung von dlink.
die hinweise sollten eigentlich ausreichen um das zu machen (ich gehe stark von aus das hier das Problem ist).

--Roland

 

[hehol]

Hallo Roland,

bist Du sicher, daß im Redboot der Ethernet-Treiber für IXP425 enthalten ist? Ich habe bisher immer gedacht, dass kein Treiber vorhanden ist.

dann sieht dieser patch fuer mich einfach falsch aus. PHY 0 und 1 muessten vertauscht werden.

#define CYGNUM_ETH0_PHY_NO 1
#define CYGNUM_ETH1_PHY_NO 0

So?

Och, die bekommen wir schon wieder ans laufen, solltest Du Dir die "geschossen" haben

Ok, dann fang' doch bitte schonmal an, das JTAG-Kabel zu löten (http://wiki.openwrt.org/OpenWrtDocs/Customizing/Hardware/JTAG_Cable).

Henning

 

[lenker]

bist Du sicher, daß im Redboot der Ethernet-Treiber für IXP425 enthalten ist? Ich habe mich bisher immer auf die Aussage von D-Link verlassen, daß kein Treiber vorhanden ist.

sicherlich nicht 100%ig, aber:
- V-Unstable-Patched/redboot/redboot/maxina_npe_ROM.ecm deutet daraufhin:

package CYGPKG_IO_ETH_DRIVERS current ;
[...]
cdl_option CYGBLD_ISO_DNS_HEADER {
    inferred_value 1 <cyg/ns/dns/dns.h>
};

- das schon genannte V-Unstable-Patched/redboot/redboot/redboot.patch, zeigt das jemand versucht hat die default werte fuer das IXDPG425 entwicklungs board auf die horst werte abzuaendern. (da wurde auch der auf dem board vorhandene Realtek PHY reingepatched)

- microcode ist auch da und funktioniert, sh.: http://www.ip-phone-forum.de/showthread.php?t=130075

- last but not least, verhaelt sich redboot bei ping, load via tftp usw. so, als haette es alles noetige da, es funktioniert halt nur nicht.

- nun ist halt noch die frage, wieviel die sourcen, die ich angeschaut hab, mit dem redboot im flash zutun haben. aber das kannst du sicher besser beurteilen.

#define CYGNUM_ETH0_PHY_NO 1
#define CYGNUM_ETH1_PHY_NO 0

So?

ja.
kein board das den IXDPG425 einsetzt hat eine solche hw konfiguration (soweit ich das z.z. beurteilen kann), deswegen wohl der aerger. Ob das wohl absicht war das so zu bauen?!

Gruss,
Roland

 

[foschi]

Ok, dann fang' doch bitte schonmal an, das JTAG-Kabel zu löten (http://wiki.openwrt.org/OpenWrtDocs/Customizing/Hardware/JTAG_Cable).

Da vermisse ich irgendwie den Smiley (im WIKI gibt es zu diesem Thema keine Inhalte). Ich habe ja nicht gesagt auf welche Art "wir" die Box wieder zum Laufen bekommen würden - meine Aussage steht aber.

[Edit foschi: ops, da sind ja doch Inhalte drin - ich schau mal.]

 

[hehol]

RedBoot mit Netzwerkunterstützung

Hallo Roland,

Deine Vermutungen bzgl. der vertauschten PHY's war vollkommen richtig! Nach dem Umtauschen in redboot/redboot-intel-ixp4xx-050425/packages/devs/eth/arm/ixdpg425/npe/v2_0/include/ixdpg425_npe.inl funktioniert der Netzwerkzugriff sofort. Nachdem ich das getestet hatte, habe ich auch noch 3_redboot.sh so modifiziert, daß der Patch, den Maxina erstellt hat, überhaupt während des Build-Vorgangs angewendet wird

Ich habe eine Archivdatei mit einem neuen Redboot, der auch Netzwerkzugriff erlaubt, an dieses Posting angehängt. Zum Austauschen benötigt man zuerst redboot_RAM.img, mit dem man Schreibzugriff auf den Flash-Speicher erhält und im zweiten Schritt kann dann redboot.bin geladen und geflasht werden. Eine Anleitung zum Austauschen findet man im RedBoot-Handbuch: http://ecos.sourceware.org/docs-latest/redboot/updating-redboot.html

Die Datei redboot_RAM.img habe ich aus dem Sourcecode von RedHat genommen, d.h. die mußte ich nicht selbst erstellen.

Gruß
Henning

P.S. Für den Notfall habe ich einen JTAG-Adapter und passende Software ...

 

[lenker]

is drauf und laeuft

# telnet 192.168.0.238 9000
Trying 192.168.0.238...
Connected to 192.168.0.238.
Escape character is '^]'.

RedBoot> version

RedBoot(tm) bootstrap and debug environment [ROM]
Red Hat certified release, version 2.02 - built 19:09:39, Apr 14 2007

Platform: D-Link Horstbox Backpack (Maxina) (IXP42X 533MHz) BE
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

RAM: 0x00000000-0x04000000, [0x00026250-0x03fc1000] available
FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.

dankeschoen

--Roland

 

[foschi]

Halte uns mal auf dem Laufenden, bitte.

 

[kabel23]

Hallo,


ich bin Anfaenger in Sachen embedded devices mit Linux. Ich Habe auch eine Horstbox und moechte da gerne redboot nutzen.

Ich benutze den TFTP Server der Horstbox um die hier vorgestellte Redboot Version aufzuspielen, jedoch scheint es nicht zu klappen auch wenn der Client mir anzeigt dass alles erfolgreich kopiert wird.

Koenntet ihr mir bitte sagen wie ich mich anlegen muss um das erfolgreich drauf zu kopieren? Ist es wichtig wann ich das tue?

Liebe Gruesse,

Kabel23

 

[arnysch]

Hab ich da was verpasst? Es liegt schon ein paar Monate zurück, dass ich bei mir den Redboot auf der Horst-Platine geflasht habe, also Nachfolgendes ohne Gewähr aus meiner Erinnerung:

• Der Redboot selbst hat keinen TFTP-Server.
• Der Original-Redboot auf Horst kann nichts über den Ethernetanschluss transferieren.
• Der Redboot von Helhol (Post #11 in diesem Thread) kann allerdings Daten/Images von einem TFTP-Server laden. Das geschieht über Eingabekommandos, wenn man sich im Redboot-Prompt befindet. Dazu muss man über die serielle Schnittstelle auf den Redboot zugreifen.
• Um den Helhol-Redboot zu flashen, muss man also erstmals über die serielle Schnittstelle zum Prompt des Original-Redboots gelangen, kann dann über die serielle Schnittstelle den neuen Redboot laden (via eines der X/Y/Z-Modem-Protokolle), und kann dann die Befehle zum Flashen eingeben.

1. Nachtrag:

• Wobei man zunächst per X/Y/Z-Modem-Protokoll einen RAM-basierten Redboot lädt und diesen startet, und über diesen dann erst den gewünschten ROM-basierten Redboot lädt und flasht.

 

[kabel23]

Hallo,

erstmals vielen Dank fuer deine Antwort.

Mhh so aehnlich hab ich mir das auch jetzt zusammengereimt, es ist nur komisch dass das transferieren problemlos geht (laut TFTP client)

Nungut, ich habe hier sehr viel gelesen und auch sonst recherchiert, aber ich bin irgendwie verwirrt, was wohl daran liegen wird dass ich einfach zuviele Informationen habe, und auch noch die ganze openWRT und Redboot Doku und co analysiert habe, aber ist es nicht moeglich etwas zu machen ohne diese Serielle Schnittstelle? Rein ueber Ethernet? Wohl kaum...

Ich wuerde micht sehr ueber eien Antwort freuen, wenns eben nicht mit Ethernet geht muss ich mir die passende Hardware zum interferieren mit der Box zulegen.

Liebe Gruesse,

Kabel23

 

[arnysch]

Kenne leider keine einfachere Möglichkeit, als den seriellen Anschluss zu benutzen.

Falls du ein Anschlusskabel mit Pfostensteckverbinder und 9-pol-Sub-D-Männchen kaufen willst: da gibt es zwei Standardversionen, und nur eine davon funktioniert mit Horst. Siehe mein Posting im Thread zum seriellen Horst-Anschluss.

Hallo,
... es ist nur komisch dass das transferieren problemlos geht (laut TFTP client)

Wenn es Dich wirklich juckt, diesem Verhalten auf den Grund zu gehen: zu welcher IP-Adresse läßt du deinen TFTP-Client sich verbinden? Gehört die zu Horst? Zu Herta? Vielleicht zu einem TFTP-Server, den du zum Experimentieren aufgesetzt hast? Funktioniert dieser scheinbare Transfer nur in den ersten Minuten nach dem Einschalten der Horstbox? Es kann durchaus sein, dass die Linux-Systeme (nicht die Bootlader) von D-Link auf Horst oder Herta nach dem Booten eine gewisse Zeit einen TFTP-Server laufen lassen, mit dem sich Firmware-Upgrades einspielen lassen; dann muss man aber die erwarteten Dateinamen und Dateiinhalte kennen.

 

[petershaus]

Könnte mir jemand bestätigen, dass man zuerst per
"load -m xmodem redboot_RAM.img"
lädt, mit dem Befehl "go" das geladene image startet.
so weit bin ich gekommen.

wie dann weiter?

muss man dann:
load -r -b %{FREEMEMLO} -m xmodem redboot.bin
fis create RedBoot

eingeben? Ich würde mir nur ungern den Redboot zerschiessen, leider ist für mich die Anleitung unter dem angegebenen Link nicht ganz eindeutig.

Ist dieser Bug bei neueren Horstbox professional immer noch vorhanden? Es scheint so zu sein, weil ich keinen Port ansprechen kann. wurde mit dem Update auf 5.0 auch redboot erneuert, oder bleibt redboot immer der gleiche?

Leider habe ich kein jtag-interface, sonst würde ich mutig drauflos schießen, so hätte ich aber lieber ein paar Tips von Euch.

Frohes Fest
Gruß Peter

 

[morpheus80]

Fehlende(s) Netzwerkinterface(s) in Linux nach flashen von modifiziertem Redboot

Ich habe das für Netzwerkzugriff modifizierte Redboot-Image geflasht. Funktioniert soweit in Redboot alles wunderbar.

Nur das Linux jetzt keinen Netzwerkadapter mehr erkennt. Mit der Original-Firmware von D-Link ist wenigstens noch ixp0 vorhanden, welches ja normalerweise zur internen Kommunikation zwischen Horst und Herta verwendet wird.
Unter OpenWRT und OpenHorst wird gleich gar kein Netzwerkinterface angezeigt, der Treiber kann das Device nicht initialisieren.


Hier die Fehlermeldung des ixp400_eth-Treibers (unter der Original D-Link Firmware):

ixp400_eth: Initializing IXP400 NPE Ethernet driver software v. 1.7 
ixp400_eth: CPU clock speed (approx) = 527 MHz
ixp400_eth: no_ixp400_sw_init != 0, no IXP400 SW core component initialisation performed
[error] ixEthMiiPhyScan : unexpected Mii PHY ID 00008201
ixp400_eth: Found PHY 0 at address 1
ixp400_eth: ixp0 is using NPEB and the PHY at address 1
ixp400_eth: Use default MAC address 00:02:b3:01:01:01 for port 0]

Der Fehler in der Funktion ixEthMiiPhyScan scheint auf die vertauschten PHY IDs hinzuweisen. Dafür kenn ich mich aber nicht gut genug aus um das näher beurteilen zu können.


ifconfig gibt folgendes aus (ebenfalls unter der Original D-Link Firmware):

ixp0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
          inet addr:192.0.2.2  Bcast:192.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:249 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:256 
          RX bytes:0 (0.0 B)  TX bytes:11862 (11.5 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:199 errors:0 dropped:0 overruns:0 frame:0
          TX packets:199 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:18606 (18.1 KiB)  TX bytes:18606 (18.1 KiB)

Wie man an der ifconfig-Ausgabe sieht ist nur ein Ethernetdevice vorhanden. Eigentlich sollten es doch aber zwei sein.


Wenn jemand weiß wo das Problem liegt, würde ich mich sehr über Hilfe freuen. Ansonsten weiß vielleicht jemand woher ich das Original Redboot-Image von D-Link bekomme.

Vielen Dank im Voraus.

 

[arnysch]

Hallo morpheus80,

Wie man an der ifconfig-Ausgabe sieht ist nur ein Ethernetdevice vorhanden. Eigentlich sollten es doch aber zwei sein.

Hmm, die Software ist vielleicht auf zwei vorbereitet. Soweit ich weiss, ist im Horst nur eins verbaut.

...Ansonsten weiß vielleicht jemand woher ich das Original Redboot-Image von D-Link bekomme.

Habe die DLink-Originalfirmware meiner beiden Horstboxen gesichert, und zwar als binäre Images der ganzen Redboot-Partitionen. Lass es mich wissen, wenn ich die für dich raussuchen soll.

Da könntest du dann die Redboot-Bootladerpartition nehmen und via RAM-Redboot bei dir drüberbügeln. Darf halt nichts schiefgehen...

Wenn jemand weiß wo das Problem liegt, würde ich mich sehr über Hilfe freuen.

Also ich hatte ja bei mir auch den Netzwerk-Redboot geflasht (war der nicht vom User helhol?). Kann aber jetzt leider zu deinem Problem nichts sagen, weil ich bei OpenHorst unbeteiligt bin.


Bin halt die andere Schiene gefahren: OpenWrt. Vorteile:

• Root-Dateisystem hochkomprimiert mit Squash-FS (read-only), darüber union-gelagert ein jffs2-Filesystem, was Änderungen erlaubt.
• Relativ viele Softwarepakete. Lassen sich auch nachträglich installieren und konfigurieren (wegen jffs2-FS).

Das offizielle OpenWrt unterstützt die HorstBox zwar nicht, im Wesentlichem muss man aber nur auf den OpenWrt-Kernel noch ein Kernel-Patchfile loslassen. Bei mir funktioniert dann: Ethernet, ISDN, USB (ehci). Analoges Telefon geht nicht.

Das Kernel-Patchfile passe ich ab und zu an den neusten OpenWrt-Kernel an. Die Kernel-Änderungen sind ursprünglich von DLink/Maxima abgeschaut.

Desweiteren habe ich ein paar OpenWrt-Zusatzpakete geschnürt:

• LCR (ISDN_Telefonanlage mit Asterisk-Anbindung)
• misdn-l1loop (isdn loopback driver von mISDN2)
• misdnuser (user space lib für mISDN2)
• hbxntpower (Kerneltreiber zur Steuerung und Überwachung der Stromversorgung des internen ISDN-S0-Bus)
• sofia-sip (user space lib für SIP/VoIP - ungetestet)
• dahdi-tools (ungetestet)
• dahdi-linux-hfcs (isdn-Treiber für Asterisk-Anbindung via DAHDI - ungetestet)

Wenn Interesse besteht, bitte nachfragen.

Gruß,
von Arnold