Messages

Hi Andy and thanks for the gen on my i7 CPU’s, zods there go’s dreaming. And they looked great in there too… I’m leaving them in place for now for safe keeping and showing off to on-lookers. Lol… You’ll never get that up and running they report, seems they are right with my CPU’s. But I’m not a quitter Ho-No...

This generation of Xeon and the I7 are very similar but the Xeon has a second QPI link that is required for dual socket operation. That is why you will never see a dual i7 board (at least not with an Intel chip set). It allows Intel to have a cheaper i7 consumer line and a much more expensive Xeon enterprise line that are essentially the same core.

I am thinking about taking the easy way out with the PSU lead kit for neatness. Not that I couldn’t have modify the leads as you have done myself being an OAP and a Ex-Technician with a dab-hand at soldering.

I can't blame you for wanting to do that. If you do decide to mod a cable then it's not difficult just a bit time consuming really.

Any advice as to where to get BIOS Flash software and HP service manual will be appreciated

Google "z800 service guide" to get the reference manual PDF. You don't need software to flash the bios. It can be done from a USB stick using an option in the BIOS setup screen.

Regards
Andy

Hi Marco, great news that you got it up and running with 2 westmere CPUs in a rev 2 board. How did you overcome the boot problems? Some users report that clearing the CMOS does the trick.

Hi Andy, I just kept on powering it on and off 

With symptoms like that it does sound like a timing issue somewhere although without HP's inside knowledge we'll never know for sure.

I notice from your photo that you installed a fan above the chip set heat sink. I also noticed how hot that thing gets and have installed a fan blowing across it inside my case. It does surprise me that the original Z800 does not have active cooling for the chipset because it's positioned below a potentially very hot graphics card and they've had to crop some of the vanes on the heatsink to allow long graphics cards to fit.

Yes, fitting into a case is hard work, please let us know how you get on!

Hi every one this is just a natter to introduces myself and to Andy nice read Re: Hacking the HP Z800 dual socket motherboard, I was browsing the web on the look out for a manual or User Guide for that very same board when I stumbled on your topic.
Like always I jump into things with both feet without thinking, what happened was I had on the shelve a couple of Intel i7 1366/950 chips sorry CPU 3.06_MHz and there on eBay was this very nice looking Motherboard and cheap I’ll have that? Yep you guessed it the very one you worked on Andy… lol ok so I have a case every much as big as yours with two large red fans at top, single large red one in front blowing in on drive bays similar to your own and it has two push in, clip in Sata bays at the front ideal for testing and formatting spear drives and super large fan on the side. An 850Watt power supply at bottom like yours, cable hides and alike on and off switch on top front like yours it has a reset and Intergraph switch all glowing red and array of four USB ports sound out mic and HHD led across top front, two DVD RW and alike below needless to say it cost a lot of coin as did the guts within stacked out 2.TB AND 3.TB Drives. A perfectly good working server and all I get is your not going to rip that apart are you dad, why not it’s my second rig I mean computer. lol       

Hi and welcome to the forum. Are you planning to do a build with the Z800 motherboard? You mentioned that your CPUs are i7. They will not work in the Z800 motherboard - it's Xeons only for the Z800.

Regards
Andy

I'm kinda happy because I've managed to finish successfully my test build.

2 Xeons X5650 and a revision 2 motherboard with the earlier boot blocker, i had a real hard time to boot for the first time but eventually it did boot   

Really apreciated for your wonderful article and support 

http://i.imgur.com/fVe81b2.png

Hi Marco, great news that you got it up and running with 2 westmere CPUs in a rev 2 board. How did you overcome the boot problems? Some users report that clearing the CMOS does the trick.

If anyone has an account on the Chinese Taobao site, this is the cable adaptor set that you need:

http://item.taobao.com/item.htm?spm=a230r.1.14.30.gZGz0F&id=40589333743&ns=1&abbucket=8#detail

Nice find Marco, look forward to hearing how you get on.

Nope, you're right, this is an omission. The IP header information should have been made available by the UDP module to both the async event API and the sync method API. I've fixed both APIs and pushed to master. See issue and commit. The examples have been updated to report the sender IP address.

When you do send a reply, do make sure you're not doing it from the async UDP event handler because you're in an IRQ context there. It's best to take what you need from the incoming event and set a 'ready' flag for your main non-IRQ loop like the demo code does.

No such thing as too many questions; the library is improving because you're reporting your experiences. By all means keep them coming.

Hi Phil,

Thanks for reporting this bug, it's fixed now on master. It was simply a case of the example code not pre-setting _datagramArrived to false in the run() method so it was undefined what it contained at runtime. When you changed the memory layout by increasing the buffer size you must have changed the storage location for _datagramArrived to somewhere that didn't contain zero.

There's no such concept as 'volatile storage'. All non-const data is in SRAM (const data is in flash). The volatile declaration is used to tell the compiler that the value may be changed by another execution context so it has to disable certain optimisations.

My immediate thought is that you're in an IRQ context and are calling a synchronous method that itself will need to wait for IRQ-related stuff to happen hence the lock-up. Setting a state flag in onAccept() and checking for it in your main loop is one way of doing this but there are better ways...

The net_tcp_server example, which I'm sure you've already seen, is the best example of how to handle a multi-connection server. Subclass TcpConnection and implement handleWrite() and handleRead(). Create yourself a state variable in your subclass which at its simplest could be 'bool _greetingSent' and set to false. You will get a callback to handleWrite() any time that a write to the peer is possible so the first time it happens is when the connection is accepted and enters the ESTABLISHED state. In your handleWrite() check your state variable and if it's 'false' then write out the greeting message (or whatever) and set the state to true. In reality you'll be maintaining a more complex state machine here based on your protocol.

The net_ftp_server example shows a much more complete example using the same basic building blocks.

I agree that getting as far as the DHCP client initialisation seems too far on in the process to be picking up a pinout error. I guess that the PHY initialisation appeared to return meaningful register bits even though those bits were probably just random. I'll take a look at the PHY registers in more detail some time to see if there's something that can be read that positively identifies the PHY as present and correct, such as a manufacturer ID code. This would catch MDC/MDIO pin errors but you do have to try to transmit/receive something to realise you've got the MII/RMII pins wrong.

Yes all the stack code with the exception of the init sequence for ST's MAC is original work. I've been working with IP networks more or less constantly since the early 90's so it's not that much of a stretch to apply that knowledge to creating a firmware stack. The language helps; a TCP/IP stack is naturally layered and object based and so lends itself well to an OO implementation.

Hi Phil,

I may be able to help you get this working. The DP83848 is definitely a supported PHY.

On your board, is it wired for MII or RMII?

Which set of pins is it wired to and are they a match for the pins in net/datalink/mac/MacDefaultPinPackage.h or net/datalink/mac/f4/MacRemapPinPackage.h? Note that there were errors in the f4 RMII remap package that I corrected in the recent 3.5.0 release.

If your PHY is wired differently then that's no problem, you can create a struct like one of the two I referenced above with the correct pinout and use its type name in your stack's DatalinkLayer declaration, e.g.

Code Select Expand


template<class TPhysicalLayer>
using MyRmiiInterface=RmiiInterface<TPhysicalLayer,MyFunkyPinPackage>;
typedef DatalinkLayer<MyPhysicalLayer,MyRmiiInterface,Mac> MyDatalinkLayer;


Which station number is your PHY listening on? The default is "1". If your PHY is on a different address then you can change it in the stack's parameters structure: params.phy_address=whatever;

Hi Phil,

The provider codes can be found in lib/include/error/ErrorProvider.h. The enumeration starts at zero and counts up so I can see that 61 is ERROR_PROVIDER_NET_DHCP. I should explicitly number that enumeration so it's easier to cross-reference. I didn't want to compile in text strings for the provider names because of the increased flash usage that would cause.

The provider-specific 'code' for DHCP can be found in lib/include/net/application/dhcp/DhcpClient.h. Again, it's an enumeration and 4 corresponds to E_FAILED which is raised when the DHCP transaction times out without a response from the DHCP server.

To debug this you'll need Wireshark. Set it up with a filter of 'bootp' and you'll see the DHCP transaction packets because DHCP is a broadcast UDP protocol so all stations on the network get to see it. The default MAC address used by stm32plus is 02-00-00-00-00-00 and this can be used to filter out stm32plus traffic from any other DHCP noise on your subnet.

Regards,
- Andy

In a temporary departure from hacking little things I thought you all might like to see how I hacked a very large thing (the HP Z800 workstation dual Xeon motherboard) into a standard PC case:

http://andybrown.me.uk/wk/2014/11/01/z800/

Definitely not as straightforward as I thought it would be when I first ordered the board on ebay but I refuse to be beaten and the outcome was a good one.

Version 3.5.0 of stm32plus has now been released.

Please do take the time to review the linked release notes because there is a runtime breaking change for projects that have been built against previous releases. I know breaking changes are painful but this one is quite trivial to fix and does enable integration with other frameworks and RTOS systems.

I just updated the article with my experience getting this to work with the popular F4 discovery board. It worked, which was surprising given the pin clashes with the discovery's onboard peripherals.